[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Host to KVM VM Communication using SLIC (setextradata)

Could you try research this one please https://www.whonix.org/wiki/Dev/KVM#Host_to_VM_Communication?

<qemu:commandline> is about using QEMU features not yet supported through Libvirt XML syntax.

Libvirt/KVM supports SLIC tables described in their manual:

acpi
The table element contains a fully-qualified path to the ACPI table. The type attribute contains the ACPI table type (currently only slic is supported) Since 1.3.5 (QEMU) Since 5.9.0 (Xen)

The right way to execute arbitrary commands from the host on the guest is via virsh console. The SE Example is for using perl or python in a guest. An alternative is a virtual network interface with sshd, but I don’t recommend it for attack surface reasons.

1 Like

It’s not about running commands. Just about passing information in a simple way. Not involving networking for simplicity / robustness of implementation.
Ideally something could be set on the host in the KVM xml file which would then be readable from inside the KVM VM.

acpi table: maybe also not great since it opens questions: what’s the default acpi table, how to create/expand the acpi table, how to not mess up something in the acpi table.

[1] https://serverfault.com/questions/727347/solidworks-activation-license-mode-is-not-supported-in-this-virtual-environment uses it for something else (license stuff). Couldn’t we use that to pass some arbitrary information too?

virsh console is similar complex as networking. How would the script know that a VM was started, how to automate script of virsh console, and how to know when it’s safe (VM boot didn’t fail/in progress) to execute. It may be possible to solve all of that but it’s more complex than [1].

acpi tables are very specific types of info relevant to guest bios info. I was confused by calling it “host to guest comms”. Can you reword it to what you are trying to accomplish?

1 Like

Given is some information on the host such as
disclaimer=done
or
bridges=no

This shall be added to host KVM XML file.

Once guest is started there should be a way to read that information from inside guest VM. Host writes it before VM starts. Once. Then guest can read it using some tool.

in https://serverfault.com/a/807687

they use

<qemu:arg value='type=0,vendor=LENOVO,version=FBKTB4AUS,date=07/01/2015,release=1.180'/>

to pass information from host to a software running inside VM which reads it. (example information passed: vendor=LENOVO) Previously nonworking software could be made to work. Related to licenses, copy protection. We don’t care about copy protection here but (ab)using the same mechanism to pass information from host to guest in a stable, simple way.

What is type=0 vs type=1 etc?
Can we pass arbitrary information there or have to change existing fields?
How to read it inside VM?

In this specific case the contents of the SLIC table is being defined in the QEMU argument, instead of pointing to a .dat file like libvirt uses. It cannot bye used to pass arbitrary info to the guest.

What you are looking for is something like Ansible for VM provisioning (modifying guest environments for any purpose), but IMO this is over kill for the task needed,

1 Like

KVM default SILC table is still empty?
This question came up in context of https://www.whonix.org/wiki/Protocol-Leak-Protection_and_Fingerprinting-Protection

Hidden SLIC table says for KVM Yes, not present

Still the case?

If SLIC empty, we could use that QEMU argument (from KVM XML file) similar to <qemu:arg value='type=0,vendor=LENOVO,version=FBKTB4AUS,date=07/01/2015,release=1.180'/> to generate SILC table pretty much regression risk free?

Yes

Yes, but what is the usecase we need this for though?

1 Like

Settings done on the host don’t need to be repeat inside guest VM. Examples:

disclaimer=done
or
bridges=no

Finishing ACW on the host saying “no bridges” could result in using the same for ACW in gateway vm.

As I said though, this can’t be used for anything else other than spoofing the appearance of the BIOS for the guest by populating the SLIC Table.

1 Like

What are the SILC fields that we can (re)write?

What’s the difference of

    <qemu:arg value='type=0

vs

    <qemu:arg value='type=1

type 2, 3, 4 etc.?

Any more examples of which values can be set?

Can this be

    <qemu:arg value='type=0,vendor=arbitrary,version=something/>

or

    <qemu:arg value='type=0,arbitrary-one=arbitrary-value,arbitrary-two=something-else/>

?

Do you think (ab)using SILC is sane?

1 Like

Documentation for this feature is almost non-existent. However from a user support thread I infer you need:

  1. a binary SLIC data file extracted from a baremetal machine (probably not a good idea to run a random one from the web so you’ll need to extract one from a trusted machine and include that in the build tarball).
  2. The data must be compliant to the SLIC Format or else it reverts to the default QEMU values. This means no possibility of using arbitrary data. I’m guessing you want to include a value that some daemon in the VM reads somehow and reacts based on it. In that case you can write the guest daemon to accept some proper value included in the custom table. So the host side would modify a VM to use a SLIC Table if ACW has been run for example and the guest side would react accordingly. Convoluted but I guess this is what you’re looking for?

https://qemu.weilnetz.de/doc/qemu-doc.html

https://lists.nongnu.org/archive/html/qemu-devel/2009-03/msg01549.html

There’s no added security attack surface. It should be alright and maybe even the guest daemon can be extended to do a variety of more actions based on it.

1 Like

An easier alternative is to set a pre-chosen disk UUID in the xml file host-side when an action is taken. This data should be readable in the guest and doesn’t need any extra files.

You can customize it so that it is a bitmasking system of sorts. Predefined actions symbolized by patterns three characters long trigger another action in the guest, for example guest daemon recognizes that 3e3 means disabling ACW notification

3e3fce45-4f53-4fa7-bb32-11f34168b82b

However if a different string is set and read by grep, it can be interpreted as disable ACW notification AND enforce sandbox profiles:

3e3pme45-4f53-4fa7-bb32-11f34168b82b

while

gthpme45-4f53-4fa7-bb32-11f34168b82b

just means enforce sandbox profiles for example.

You potentially have 10/11 custom actions you can run simultaneously using the entire UUID string length. I don’t know if there is a more efficient use of the string to increase the number of actions.

EDIT:

UUID is readily obtainable with sudo dmidecode

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]