Bug 1560946 - [RFE] support luks encrypted volume in disk pool
Summary: [RFE] support luks encrypted volume in disk pool
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.6
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: John Ferlan
QA Contact: yisun
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-27 10:26 UTC by yisun
Modified: 2018-10-30 09:55 UTC (History)
7 users (show)

Fixed In Version: libvirt-4.4.0-1.el7
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2018-10-30 09:53:26 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:3113 None None None 2018-10-30 09:55:50 UTC

Description yisun 2018-03-27 10:26:59 UTC
Description of problem:
[RFE] support luks encrypted volume in disk pool

Version-Release number of selected component (if applicable):
libvirt-3.9.0-14.virtcov.el7_5.1.x86_64

pls note:
this is a extending test of "Bug 1427049 - [RFE] encrypted volumes support on logical storage pool", so if logical pool can support luks encrypted vol, maybe disk pool should also support that, since we definitely can do "qemu-img create -f luks" to a disk partition.

How reproducible:
100%

Steps to Reproduce:
1. Having a disk pool as follow:
## virsh pool-dumpxml disk-pool
<pool type='disk'>
  <name>disk-pool</name>
  <uuid>eab0f7cb-c2ef-4f7b-a6b6-1def04fb61be</uuid>
  <capacity unit='bytes'>512</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
    <device path='/dev/sdf'>
      <freeExtent start='512' end='512'/>
    </device>
    <format type='dos'/>
  </source>
  <target>
    <path>/dev</path>
  </target>
</pool>

2. having a libvirt secret
## virsh secret-list | grep luks
 726f4691-fbb6-44cf-aa99-75e3fe41080c  volume /var/libvirt/images/luks.img

3. prepare vol xml
## cat vol.xml
<volume>
<name>sdf1</name>
<allocation>10485760</allocation>
<capacity>10485760</capacity>
<target>
<encryption format="luks"><secret type="passphrase" uuid="726f4691-fbb6-44cf-aa99-75e3fe41080c" /></encryption>
</target>
</volume>

4. try to create the volume
## virsh vol-create disk-pool vol.xml
error: Failed to create vol from /root/vol.xml
error: unsupported configuration: storage pool does not support encrypted volumes


Actual results:
cannot create encrypted vol in disk pool

Expected results:
can create

Comment 3 John Ferlan 2018-05-24 23:53:14 UTC
Posted a patch upstream :

https://www.redhat.com/archives/libvir-list/2018-May/msg01886.html

In my testing ensure that the fix for bz1400475 is also applied since the creation of the /dev/XXX device used for encryption will go through the same path.

Comment 4 John Ferlan 2018-05-29 15:29:38 UTC
A v2 was posted after review:

https://www.redhat.com/archives/libvir-list/2018-May/msg02109.html

after a slight adjustment, it was pushed upstream:

commit 57d6df39bd7eb8166fee68f4b6da03c0cb0802bf (origin/master, origin/HEAD, master, bz1560946)
Author: John Ferlan <jferlan@redhat.com>
Date:   Mon May 21 06:40:58 2018 -0400

    storage: Add capability to use LUKS encryption for disk backend
    
...
    
    Similar to the the Logical backend, use qemu-img on the created
    disk partition device to set up for LUKS encryption. Secret mgmt
    for the device can be complicated by a reboot possibly changing
    the path to the device if the infrastructure changes.
    
...

$ git describe 57d6df39bd7eb8166fee68f4b6da03c0cb0802bf
v4.3.0-373-g57d6df39bd
$

Comment 6 yisun 2018-06-21 07:43:30 UTC
Verified on: libvirt-4.4.0-2.virtcov.el7.x86_64

1. Having a disk pool
# virsh pool-dumpxml disk-pool
<pool type='disk'>
  <name>disk-pool</name>
  <uuid>07ad41c4-dfdd-4e1d-a3f6-4feded205a88</uuid>
  <capacity unit='bytes'>2089221120</capacity>
  <allocation unit='bytes'>528187904</allocation>
  <available unit='bytes'>1561000960</available>
  <source>
    <device path='/dev/sdb'>
      <freeExtent start='528220160' end='2089221120'/>
    </device>
    <format type='dos'/>
  </source>
  <target>
    <path>/dev</path>
  </target>
</pool>

2. prepare a libvirt secret with password='redhat'
# cat secret.xml 
<secret ephemeral='no' private='yes'>
    <description>luks secret for dp vol1</description>
    <usage type='volume'>
       <volume>/dev/sdb1</volume>
    </usage>
</secret>

# virsh secret-define secret.xml 
Secret 34c1f8fa-8af7-439d-ba4f-64fc13819263 created

# MYSECRET=`printf %s "redhat" | base64`

# virsh secret-set-value 34c1f8fa-8af7-439d-ba4f-64fc13819263 $MYSECRET
Secret value set

3. Create a luks encrypted vol
# cat vol.xml 
<volume>
  <name>sdb1</name>
  <capacity unit='M'>500</capacity>
  <target>
    <encryption format='luks'>
       <secret type='passphrase' uuid='34c1f8fa-8af7-439d-ba4f-64fc13819263'/>
       <cipher name='twofish' size='256' mode='cbc' hash='sha256'/>
       <ivgen name='plain64' hash='sha256'/>
    </encryption>
  </target>
</volume>

# virsh vol-create disk-pool vol.xml 
Vol sdb1 created from vol.xml

4. Use the correct secret with the vol in vm
# virsh dumpxml avocado-vt-vm1
...
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/sdb1'/>
      <target dev='sdb' bus='scsi'/>
      <encryption format='luks'>
        <secret type='passphrase' uuid='34c1f8fa-8af7-439d-ba4f-64fc13819263'/>
      </encryption>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>

# virsh start avocado-vt-vm1
Domain avocado-vt-vm1 started

5. Set another secret(uuid=799ef9b1-f855-4317-8cce-8160fc8790fd) with password='greenhat' and use it in vm
# virsh dumpxml avocado-vt-vm1
...
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/sdb1'/>
      <target dev='sdb' bus='scsi'/>
      <encryption format='luks'>
        <secret type='passphrase' uuid='799ef9b1-f855-4317-8cce-8160fc8790fd'/>
      </encryption>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>

# virsh start avocado-vt-vm1
error: Failed to start domain avocado-vt-vm1
error: internal error: qemu unexpectedly closed the monitor: profiling:/builddir/build/BUILD/libvirt-4.4.0/src/util/.libs/libvirt_util_la-virbitmap.gcda:Cannot open
profiling:/builddir/build/BUILD/libvirt-4.4.0/src/util/.libs/libvirt_util_la-virauthconfig.gcda:Cannot open
profiling:/builddir/build/BUILD/libvirt-4.4.0/src/util/.libs/libvirt_util_la-virauth.gcda:Cannot open
profiling:/builddir/build/BUILD/libvirt-4.4.0/src/util/.libs/libvirt_util_la-viraudit.gcda:Cannot open
profiling:/builddir/build/BUILD/libvirt-4.4.0/src/util/.libs/libvirt_util_la-virarptable.gcda:Cannot open
profiling:/builddir/build/BUILD/libvirt-4.4.0/src/util/.libs/libvirt_util_la-virarch.gcda:Cannot open
profiling:/builddir/build/BUILD/libvirt-4.4.0/src/util/.libs/libvirt_util_la-viralloc.gcda:Cannot open
2018-06-21T07:37:45.369445Z qemu-kvm: -drive file=/dev/sdb1,key-secret=scsi0-0-0-1-luks-secret0,format=luks,if=none,id=drive-scsi0-0-0-1: Invalid password, cannot unlock any keyslot

Comment 8 errata-xmlrpc 2018-10-30 09:53:26 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3113


Note You need to log in before you can comment on or make changes to this bug.