Re: [libvirt] [PATCH] storage: Add capability to use LUKS encryption for disk backend
On Tue, May 29, 2018 at 07:49:50 -0400, John Ferlan wrote:
On 05/29/2018 07:02 AM, Peter Krempa wrote:
> On Thu, May 24, 2018 at 19:50:09 -0400, John Ferlan wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1560946
>>
>> Following the model of the Logical backend, use qemu-img on
>> the created device to set up for LUKS encryption.
>>
>> Signed-off-by: John Ferlan <jferlan(a)redhat.com>
>> ---
>>
>> works much better with the settle patch applied from:
>>
>> https://www.redhat.com/archives/libvir-list/2018-May/msg01847.html
>>
>>
>> src/storage/storage_backend_disk.c | 43 ++++++++++++++++++++++++--------------
>> 1 file changed, 27 insertions(+), 16 deletions(-)
>>
>> diff --git a/src/storage/storage_backend_disk.c
b/src/storage/storage_backend_disk.c
>> index 7b4549c34d..a3003fd0b5 100644
>> --- a/src/storage/storage_backend_disk.c
>> +++ b/src/storage/storage_backend_disk.c
>
> I must say that I'm not a fan of adding features to the 'disk' backend.
> Using the disk backend is borderline insane for managing disk
> partitions.
>
> [...]
>
So in your opinion, does that mean the above bug should just closed? I
Well, in my opinion this feature will not be used much ... or perhaps at
all.
Whether it can be closed or not depends on the motivation of the
ones filing it and specifically on the motivation of Red Hat keeping it
on their product tracker.
I just wanted to point that out. Obviously contributions to upstream are
welcome so if a feature is desired and contributors implement it, it's
marginal usefulnes for most cases should not interfere with it's
upstream acceptance as it might be useful for somebody.
don't want to assume anything about anyone's sanity ;-). Even
though to
Well, my comment is specifically targetted on using libvirt to manage
partitions. Using libvirt XML to describe partitioning changes is a very
strange concept and users of it must be very brave.
a degree I agree as I found this particularly odd to create/pass a
device/partition to qemu-img. In a way I was surprised it worked, but
Passing raw devices to qemu-img or qemu itself is done regularly. Even
qcow2 formatted logical volumes are used e.g. by oVirt
then again since the Logical back-end also allows encryption of a
single
volume - doing so for disk volumes would appear to be similar, albeit
strange.
Depending on configuration it may not stand the test of time (e.g.
reboot) either especially if your infrastructure changes - you'd have to
recreate the secret for a different /dev/sdXN.
Both paragraphs above can be applied to logical volumes too, there
really isn't much difference.
>> @@ -893,6 +887,12 @@ virStorageBackendDiskCreateVol(virStoragePoolObjPtr pool,
>> goto cleanup;
>> }
>>
>> + /* If we're going to encrypt using LUKS, then we could need up to
>> + * an extra 2MB for the LUKS header - so account for that now */
>> + if (vol->target.encryption &&
>> + vol->target.encryption->format ==
VIR_STORAGE_ENCRYPTION_FORMAT_LUKS)
>> + endOffset += 2 * 1024 * 1024;
>
>
> I don't think it's a good idea to change 'endOffset' after calling
> virStorageBackendDiskPartBoundaries as the function is looking up space
> in the existing partition table. With this if the size is just right and
> you increase it afterwards the partition will not fit in the place found
> by that function.
>
Oh right, sigh. Brain cramp. If this were to be done, then need to
adjust vol->target.capacity before virStorageBackendDiskPartBoundaries
Yes. Specifically only the value passed to virStorageBackendDiskPartBoundaries
since you want to keep the capacity desired by the user intact.
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)