On Thu, Sep 02, 2021 at 05:55:20AM +0000, Or Ozeri wrote: > Hi, > > > I wanted to get your advice on a patch I'm preparing for libvirt. > It touches the code-path that allows using LUKS encryption on top of an RBD image. > > > We recently added LUKS and LUKS2 encryption support in Ceph's librbd. > We exposed this in qemu in a recent patch by adding new optional > "encrypt" member to BlockdevOptionsRbd. > This patch was included in the recent release of qemu 6.1. > To enable libvirt users to use librbd encryption, we need libvirt > to use this new "encrypt" when it builds the blockdev options for RBD. > > > The interesting question is how to define the libvirt XML syntax that > will trigger the use of librbd encryption. > My thought was to use the already existing <encryption> tag. > In that case, we just need to add a new format VIR_STORAGE_ENCRYPTION_FORMAT_LUKS2 to the enum virStorageEncryptionFormatType. > This type will be checked in qemuBlockStorageSourceGetRBDProps. I don't think we want to switch impls based on luks1 vs luks2, because that will create trouble in future when/if QEMU's native impl gains Luksv2 support. So I think we need an explicit way to request librbd encryption, even for luks2. > The problem with this approach is that it only works for LUKS2. > librbd encryption also supports LUKS1. > We want to allow the user to choose between the qemu LUKS implementation and the librbd one. > One reason to keep support both is that on the one hand librbd only supports XTS mode. > On the other hand, qemu implementation will not support a chain of uniquely encrypted RBD images (each serving as a backing store for the previous one). I think I asked this before on qemu-devel, but I can't find the answer, but can you explain the RBB backing store chain problem ? QEMUs' LUKS driver can be layered on top of any QEMU block protocol driver. So if there are multiple RBD layers in the qemu -blockdev config, we can layer LUKS over each one independantly. In any case, I agree we need a way to request a specific luks impl. > So we need a way in the XML API to support both implementations. > Our current thought is to add a new "engine" attribute to the encryption tag. > By default, encryption will use the QEMU LUKS implementation, unless <encryption engine='rbd' ...> is specified. > To make this more general, we can have engine='backend' instead of engine='rbd' to denote that the encryption is to be delegated to the backend storage properties (instead of the format properties). I don't think we'll ever do it, but conceptually libvirt could even integrate with host kernel cryptsetup tools. Having an 'engine' attribute feels like a decent enough idea. Maybe engine='host|qemu|builtin' - host - the cryptosetup/kernel driver - qemu - qemu's custom luks driver - builtin - the librbd (or equiv) builtin driver Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
