Sending logical volumes (partitions) to VMs

User Support
1

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?

1 Like
2

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:

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.

4 Likes
3

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?

2 Likes
4

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

5

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

6

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.

1 Like
7

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?

8

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

1 Like
9

It took me a while to get to it, but now I have this fully set up. It works perfectly!

Some additional questions about the qubes layer to this. I encrypted the drive, when I write to it in a VM will dom0 encrypt the data?

I also made my logical volume mirrored, when I write to it, will dom0 be mirroring it?

My question is more or less, does everything work just as on a plain Linux installation without VMs?

Also, is there a good way to make the attachments persistent? When I reboot the devices change names and my VMs can no longer boot because the attached device doesn’t exist.

In the mean time I scripted the process without the persistent flag, but if I reboot a VM I will have to manually reattach it using the qubes devices widget.

Thank you very much for all the help. :slight_smile:

10

Yes to both. The VM is not even aware of the underlying layers, so all of that is done by dom0.

I don’t have a good suggestion for that, sorry. There’s an open ticket:

1 Like
11

You can try to use libxl hook like this:

1 Like