Support for raw (unformatted) volumes

[DemiMarie]

This would make Stratis much more useful for virtualization, where an entire block device is passed into a VM. Raw volumes must not be scanned by udev as their contents are potentially attacker-controlled.

[mulkieran]

Testing convert to discussion..

[DemiMarie]

Worked 😄

[jbaublitz]

Hi @DemiMarie! It looks like you're working on behalf of Qubes. Is this correct?

I want to get a little bit more information on what specifically you're requesting. We have talked about exposing block devices but there's been no motion on that yet. Ideally what would be looking to expose via this interface? Would you be looking for the entire Stratis stack other than the filesystems on top? If so this would mainly correspond to exposing a set up pool as a block device which I think is doable from what I've seen. Most likely, the end result would look something like a single thin device on top of a thin pool without an XFS filesystem on it that could be consumed as a block device by users. If this is not what you're asking for, could you specify further?

As for your comment about udev, I'd like to dig into this a little bit deeper. Currently, we rely fairly heavily on udev for device detection. I'd like to get a little bit more information on exactly what part of udev you object to. For example, I'm assuming uevents triggered by the kernel are not the problem. Is the primary concern the rules that do can execute arbitrary commands? Is it automatically scanning the superblock implicitly with blkid? I'd like to get more information on exactly which part of the udev scanning process you're threat modeling so that I can give you a better answer on whether we can provide you with an option that still preserves our functionality for preventing users from overwriting existing used devices while also giving you the ability to do what you need to to avoid the parts of udev that you're concerned about.

[DemiMarie]

We do care what the contents of devices are mainly because we're trying to put guardrails in place for our users. Generally we prevent multipath devices, devices with partitions, and devices with recognized superblocks from being formatted as a pool. We require the user to manually wipe these before Stratis will accept them as part of a new pool. This is to prevent users from accidentally destroying devices that they may want to preserve. This part is incorporated into our actual code so this is not configurable via udev rules. Furthermore, we use udev pretty heavily when assembling existing pools on start up of Stratis.

Scanning the devices that are part of a pool is fine. It’s the devices that are exposed by Stratis (the thin volumes) that need to not be scanned.

[DemiMarie]

@mulkieran I'm curious if this is something you have thoughts on. My thought here is that we'd sacrifice some of the usability and core functionality by not checking the storage prior to claiming it.

Oh absolutely. I would expect that to be checked!

[jbaublitz]

Okay then it sounds like we may be able to point you in the right direction to prevent that from happening in Qubes.

[jbaublitz]

@DemiMarie We've gotten another request for exposing block devices as opposed to filesystems! Likely what we'd want to do for that case is provide the ability to expose many thin devices on top of a pool instead of just a single thin device device. Is that something you'd be interested in as well? I don't see any drawbacks personally as this would just provide additional flexibility, but I wanted to run this by you first.

[DemiMarie]

Yes, that is exactly what I was looking for. Qubes OS needs to be able to create, snapshot, and destroy thin devices from a pool at runtime, and it needs to do so with very low latency. Creating a VM involves creating three devices (one fresh and two snapshot), and it is done in response to ordinary user actions in the GUI, so latency really matters. The last time I benchmarked LVM2 it was slow enough to noticeably impact system responsiveness if I recall correctly.

One additional requirement is that zeroing of newly provisioned chunks must be enabled. Not zeroing them would be a serious security hole, since the contents of the chunks are visible to untrusted guests. This is not an issue when all of the thin volumes are used by local file systems, since zeroing freshly allocated chunks is the file system’s responsibility. It is a requirement when exporting the thin volumes via iSCSI or similar.