Sending logical volumes (partitions) to VMs

org · March 29, 2024, 2:22pm

Consider this scenario, I have a 2TB hard drive which I create two logical volumes on, split 50/50.

I can now send these volumes to separate VMs and access them, how safe is this?

My understanding is that Qubes OS is already doing this, is it equally safe if I do it myself? What can a VM access if it’s sent a partition/logical volume? Can it read directly from the entire device to get data across VMs?

rustybird · March 29, 2024, 2:58pm

One thing to watch out for is that if you let a VM write to a dom0 block device (in this case, the additional logical volume), the VM-controlled, potentially malicious data now stored on that block device must not be parsed in dom0. By default, udev would scan any block devices’s data for filesystems etc., so for the normal logical volumes managed by the lvm_thin Qubes OS storage driver (whose names all begin with vm-) there are some udev rules in /usr/lib/udev/rules.d/ that prevent them from being scanned:

github.com

QubesOS/qubes-core-admin-linux/blob/v4.2.20/system-config/12-qubes-ignore-lvm-devices.rules#L4


      
          # do not edit this file, it will be overwritten on update
          
          # Skip VM images managed by lvm storage pool
          ACTION!="remove", SUBSYSTEM=="block", ENV{DM_UUID}=="LVM-*", ENV{DM_LV_NAME}=="|vm-*" ENV{DM_UDEV_DISABLE_DISK_RULES_FLAG}="1", ENV{UDEV_DISABLE_PERSISTENT_STORAGE_RULES_FLAG}="1"
          
          # vim: set ft=udevrules ff=unix fenc=UTF-8 eol:

github.com

QubesOS/qubes-core-admin-linux/blob/v4.2.20/system-config/99z-qubes-mark-ready.rules#L7


      
          SUBSYSTEM!="block", GOTO="qubes-rule-end"
          ACTION=="remove", GOTO="qubes-rule-end"
          
          # Skip devices that might contain untrusted data.  We won’t be doing any other
          # processing on them (and rightly so).
          KERNEL=="loop*", ATTR{loop/backing_file}!="/var/lib/qubes/vm-kernels/*", ENV{SYSTEMD_READY}="1"
          ENV{DM_LV_NAME}=="vm-*", ENV{SYSTEMD_READY}="1"
          ENV{DM_UUID}=="CRYPT-*", ENV{DM_NAME}!="swap|luks-*", ENV{SYSTEMD_READY}="1"
          
          # Tell udev that zvols are ready.
          KERNEL=="zd[0-9]*", SUBSYSTEM=="block", ACTION=="add|change", ENV{SYSTEMD_READY}="1"
          
          LABEL="qubes-rule-end"
          
          # vim: set ft=udevrules ff=unix fenc=utf-8:

To replicate this, you’ll probably want to give your additional logical volumes names that start with vm- too. Assuming that they’re on a separate LVM pool anyway (one that’s not used by the lvm_thin Qubes OS storage driver) I think that prefix should not conflict with anything.

No.

org · March 30, 2024, 5:01pm

Hey, thanks. This is exactly the type of information I was looking for. For clarity’s sake, do I only have to prepend vm- to the name argument when creating a volume using lvcreate for this to apply?

rustybird · March 30, 2024, 5:14pm

Yes that should do it (but I haven’t tested this)

org · April 8, 2024, 9:34pm

This feels very important due to the Dom0 risk. @Demi , as the author of that file, would you like to add your thoughts?

Demi · April 8, 2024, 11:52pm

If you start the names with vm-, it ought to be just as safe as what Qubes OS does internally. Be sure to never mount the volumes in dom0 or run fsck on them. Creating a snapshot should be fine, so long as the new volume has a name that also begins with vm-.

I say “ought to” and “should” because I haven’t actually tested this.

org · April 19, 2024, 9:08am

Now that I’ve tried this, I realized that if the names start with vm-, they won’t be detected as devices and I can’t send them to their destination.

If I create one without that prefix, it will show up in the devices widget, and I can attach it to a VM.

They are still available under /dev/vgname/lvname, can I attach them to VMs somehow through that?

rustybird · April 19, 2024, 10:35am

Oh right, you have to expose the /dev/vgname/lvname block device like in step 1 here: