This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1301019 - [RFE] add support for LUKS disk encryption format driver w/ RBD, iSCSI, and qcow2
[RFE] add support for LUKS disk encryption format driver w/ RBD, iSCSI, and q...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.3
Unspecified Unspecified
medium Severity unspecified
: rc
: ---
Assigned To: Daniel Berrange
pingl
: FutureFeature
: 1297980 (view as bug list)
Depends On:
Blocks: 1230405 1305606 1352501 1411525 1419712 1262120 1301021
  Show dependency treegraph
 
Reported: 2016-01-22 05:56 EST by Daniel Berrange
Modified: 2017-04-24 22:04 EDT (History)
17 users (show)

See Also:
Fixed In Version: qemu-kvm-rhev-2.6.0-24.el7
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1301021 (view as bug list)
Environment:
Last Closed: 2016-11-07 15:56:54 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
coredump file (711.91 KB, application/x-gzip)
2016-08-23 02:25 EDT, yisun
no flags Details
virsh capabilities (9.89 KB, text/plain)
2016-08-29 03:16 EDT, yangyang
no flags Details
result for qemu-iotests of luks format (27.41 KB, text/plain)
2016-09-22 02:30 EDT, pingl
no flags Details

  None (edit)
Description Daniel Berrange 2016-01-22 05:56:14 EST
Description of problem:
QCow2 currently has a built-in AES encryption feature, however, it is broken by design and does not offer acceptable security. It is possible to have QEMU access a dm-crypt device setup by the cryptosetup tools in the host, however, that requires that the backend storage be exposed via a kernel block device driver. In OpenStack there is a move towards using the in-QEMU network clients for everything, as they have proved more reliable to manage than kernel + usersapce tools. The LUKS format used by dm-crypt, is very well designed and desirable to use. As such OpenStack requires that QEMU gain support to use LUKS directly as a layer above its native RBD and iSCSI drivers, as well as to integrate it in QCow2 as a  replacement for the current broken AES support.

Most recent posting of this work upstream

https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg03871.html
Comment 2 Ademar Reis 2016-05-04 12:17:57 EDT
*** Bug 1297980 has been marked as a duplicate of this bug. ***
Comment 4 yisun 2016-08-17 06:09:11 EDT
When try to start a vm with luks image, it failed because not whitelisted. Pls help to confirm. 

virsh dumpxml virtlab_test | grep luks -a10
...
    <disk type='volume' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source pool='luks' volume='luks_1.img'/>
      <target dev='vdb' bus='virtio'/>
      <encryption format='luks'>
        <secret type='passphrase' uuid='4ff78f8c-6ee6-4a8d-b638-2b59d5d49279'/>
      </encryption>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </disk>
...

# virsh start virtlab_test
error: Failed to start domain virtlab_test
error: internal error: process exited while connecting to monitor: 2016-08-17T10:06:37.533147Z qemu-kvm: -drive file=/var/lib/libvirt/images/luks/luks_1.img,key-secret=virtio-disk1-luks-secret0,format=luks,if=none,id=drive-virtio-disk1: Driver 'luks' is not whitelisted
Comment 5 pingl 2016-08-18 02:17:40 EDT
Hi Daniel,

The issue is fixed in qemu 2.6, but i have no clue how to verify it. Could you help to share the steps to verify this bug fix? Thanks in advance.
Comment 6 Daniel Berrange 2016-08-18 03:50:34 EDT
Moving back to POST since the RPM build did not enable LUKS
Comment 7 yisun 2016-08-22 08:50:59 EDT
Hi Daniel,
From libvirt perspective, I wrote a script to create luks volume with all possible parameters. As follow:
...
cipher_names = ["aes","des","cast5","serpent","twofish","invalid"]
cipher_sizes = ["256","192","128","6"] # 6 is invalid value for negative test
cipher_modes = ["cbc","xts","ecb","invalid"]
cipher_hashes = ["md5","sha1","sha256","invalid"]
ivgen_names = ["plain","plain64","essiv","invalid"]
ivgen_hashes = ["md5","sha1","sha256","invalid"]
...

There are 6144 possible combinations. And some questions need your confirmation
1. DES not supported as expected? As follow:
# qemu-img create -f luks --object secret,id=sec0,data=`printf %s "redhat" | base64`,format=base64 -o key-secret=sec0,cipher-alg=des-rfb 1.img 1G

Formatting '1.img', fmt=luks size=1073741824 key-secret=sec0 cipher-alg=des-rfb
qemu-img: 1.img: Algorithm 'des-rfb' not supported

2. when cipher-alg is aes/twofish/serpent, and ivgen-alg=essiv,ivgen-hash-alg=sha1, there always a "No AES/Serpent/Twofish cipher with key size 20 available" error, not quite understand why the key size is 20 here (128/196/258 passed actually)

# qemu-img create -f luks --object secret,id=sec0,data=`printf %s "redhat" | base64`,format=base64 -o key-secret=sec0,cipher-alg=aes-128,cipher-mode=ecb,hash-alg=sha256,ivgen-alg=essiv,ivgen-hash-alg=sha1 1.img 1G

Formatting '1.img', fmt=luks size=1073741824 key-secret=sec0 cipher-alg=aes-128 cipher-mode=ecb ivgen-alg=essiv ivgen-hash-alg=sha1 hash-alg=sha256
qemu-img: 1.img: No AES cipher with key size 20 available

3. (THIS MAYBE A BUG) when cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5(/sha1/sha256, this value doesn't matter),ivgen-alg=essiv,ivgen-hash-alg=md5 there will be a "unexpected fatal signal 11"

# cat /tmp/luks_vol.xml
<volume>
    <name>luks1.img</name>
    <capacity unit='G'>1</capacity>
    <target>
        <path>/var/lib/libvirt/images/luks/luks1.img</path>
        <format type='raw'/>
        <encryption format='luks'>
            <secret type='passphrase' uuid='f981dd17-143f-45bc-88e6-ed1fe20ce9da'/>
            <cipher name='cast5' size='128' mode='xts' hash='md5'/>
            <ivgen name='essiv' hash='md5'/>
        </encryption>
    </target>
</volume>

Running: virsh vol-create luks /tmp/luks_vol.xml
error: Failed to create vol from /tmp/luks_vol.xml
error: internal error: Child process (/usr/bin/qemu-img create -f luks --object secret,id=luks1.img_luks0,file=/var/run/libvirt/storage/luks.luks1.img.secret.eaTuyc -o key-secret=luks1.img_luks0,cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5,ivgen-alg=essiv,ivgen-hash-alg=md5 /var/lib/libvirt/images/luks/luks1.img 1048576K) unexpected fatal signal 11
Comment 8 Miroslav Rezanina 2016-08-22 14:25:41 EDT
Fix included in qemu-kvm-rhev-2.6.0-22.el7
Comment 9 Daniel Berrange 2016-08-22 14:51:26 EDT
(In reply to yisun from comment #7)
> Hi Daniel,
> From libvirt perspective, I wrote a script to create luks volume with all
> possible parameters. As follow:
> ...
> cipher_names = ["aes","des","cast5","serpent","twofish","invalid"]
> cipher_sizes = ["256","192","128","6"] # 6 is invalid value for negative test
> cipher_modes = ["cbc","xts","ecb","invalid"]
> cipher_hashes = ["md5","sha1","sha256","invalid"]
> ivgen_names = ["plain","plain64","essiv","invalid"]
> ivgen_hashes = ["md5","sha1","sha256","invalid"]
> ...
> 
> There are 6144 possible combinations.

Ok, it is important to note you cannot assume all combinations are valid.

eg, using xts + essiv, while technically possible, is nothing something you'd ever do in practice.

Also, the ivgen hashses are only relevant when using essiv.

The QEMU iotest 149 gives a representative set of combinations that cover the "normal" combinations you'd expect 99% of people to use

http://git.qemu.org/?p=qemu.git;a=blob;f=tests/qemu-iotests/149;h=84072513db0bb3331214f752c3f1654297824c65;hb=HEAD


>                                       And some questions need your
> confirmation
> 1. DES not supported as expected? As follow:
> # qemu-img create -f luks --object secret,id=sec0,data=`printf %s "redhat" |
> base64`,format=base64 -o key-secret=sec0,cipher-alg=des-rfb 1.img 1G
> 
> Formatting '1.img', fmt=luks size=1073741824 key-secret=sec0
> cipher-alg=des-rfb
> qemu-img: 1.img: Algorithm 'des-rfb' not supported

'des-rfb' != 'des'.

'des-rfb' is a special crippled version of des used only by RFB (aka VNC).
It is not at all relevant to LUKS.

We've no intention of adding real support for DES to LUKS since it is a broken cipher
 
> 2. when cipher-alg is aes/twofish/serpent, and
> ivgen-alg=essiv,ivgen-hash-alg=sha1, there always a "No AES/Serpent/Twofish
> cipher with key size 20 available" error, not quite understand why the key
> size is 20 here (128/196/258 passed actually)
> # qemu-img create -f luks --object secret,id=sec0,data=`printf %s "redhat" |
> base64`,format=base64 -o
> key-secret=sec0,cipher-alg=aes-128,cipher-mode=ecb,hash-alg=sha256,ivgen-
> alg=essiv,ivgen-hash-alg=sha1 1.img 1G
> 
> Formatting '1.img', fmt=luks size=1073741824 key-secret=sec0
> cipher-alg=aes-128 cipher-mode=ecb ivgen-alg=essiv ivgen-hash-alg=sha1
> hash-alg=sha256
> qemu-img: 1.img: No AES cipher with key size 20 available
> 

The cipher is used in two places - first for ciphering actual disk data, and second for ciphering the Initialization vector with essiv.  The key size you provide only relates to cipher of disk data.  The key size used when ciphering initialization vectors is determined indirectly by the ivgen hash algorithm. You chose SHA1, which has a digest size of 20 bytes / 160 bits. So it is trying to find a cipher keysize of 160, which is not supported.

IOW, use of SHA1 is simply not compatible with the ciphers you list. Realistically only sha256 / sha512 make sense as options.

> 3. (THIS MAYBE A BUG) when
> cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5(/sha1/sha256, this value
> doesn't matter),ivgen-alg=essiv,ivgen-hash-alg=md5 there will be a
> "unexpected fatal signal 11"
> 
> # cat /tmp/luks_vol.xml
> <volume>
>     <name>luks1.img</name>
>     <capacity unit='G'>1</capacity>
>     <target>
>         <path>/var/lib/libvirt/images/luks/luks1.img</path>
>         <format type='raw'/>
>         <encryption format='luks'>
>             <secret type='passphrase'
> uuid='f981dd17-143f-45bc-88e6-ed1fe20ce9da'/>
>             <cipher name='cast5' size='128' mode='xts' hash='md5'/>
>             <ivgen name='essiv' hash='md5'/>
>         </encryption>
>     </target>
> </volume>
> 
> Running: virsh vol-create luks /tmp/luks_vol.xml
> error: Failed to create vol from /tmp/luks_vol.xml
> error: internal error: Child process (/usr/bin/qemu-img create -f luks
> --object
> secret,id=luks1.img_luks0,file=/var/run/libvirt/storage/luks.luks1.img.
> secret.eaTuyc -o
> key-secret=luks1.img_luks0,cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5,
> ivgen-alg=essiv,ivgen-hash-alg=md5 /var/lib/libvirt/images/luks/luks1.img
> 1048576K) unexpected fatal signal 11

Yep, seeing a signal 11 is always a bug. I'll investigate this
Comment 11 Daniel Berrange 2016-08-22 16:04:37 EDT
(In reply to Daniel Berrange from comment #9)
> > 3. (THIS MAYBE A BUG) when
> > cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5(/sha1/sha256, this value
> > doesn't matter),ivgen-alg=essiv,ivgen-hash-alg=md5 there will be a
> > "unexpected fatal signal 11"
> > 
> > # cat /tmp/luks_vol.xml
> > <volume>
> >     <name>luks1.img</name>
> >     <capacity unit='G'>1</capacity>
> >     <target>
> >         <path>/var/lib/libvirt/images/luks/luks1.img</path>
> >         <format type='raw'/>
> >         <encryption format='luks'>
> >             <secret type='passphrase'
> > uuid='f981dd17-143f-45bc-88e6-ed1fe20ce9da'/>
> >             <cipher name='cast5' size='128' mode='xts' hash='md5'/>
> >             <ivgen name='essiv' hash='md5'/>
> >         </encryption>
> >     </target>
> > </volume>
> > 
> > Running: virsh vol-create luks /tmp/luks_vol.xml
> > error: Failed to create vol from /tmp/luks_vol.xml
> > error: internal error: Child process (/usr/bin/qemu-img create -f luks
> > --object
> > secret,id=luks1.img_luks0,file=/var/run/libvirt/storage/luks.luks1.img.
> > secret.eaTuyc -o
> > key-secret=luks1.img_luks0,cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5,
> > ivgen-alg=essiv,ivgen-hash-alg=md5 /var/lib/libvirt/images/luks/luks1.img
> > 1048576K) unexpected fatal signal 11
> 
> Yep, seeing a signal 11 is always a bug. I'll investigate this

I'm unable to reproduce that crash. Can you provide information about what version of QEMU you saw this with, what OS platform, etc. Also could you capture a stack trace with GDB
Comment 12 yisun 2016-08-23 02:25 EDT
Created attachment 1193155 [details]
coredump file
Comment 13 yisun 2016-08-23 02:26:52 EDT
(In reply to Daniel Berrange from comment #11)
> (In reply to Daniel Berrange from comment #9)
> > > 3. (THIS MAYBE A BUG) when
> > > cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5(/sha1/sha256, this value
> > > doesn't matter),ivgen-alg=essiv,ivgen-hash-alg=md5 there will be a
> > > "unexpected fatal signal 11"
> > > 
> > > # cat /tmp/luks_vol.xml
> > > <volume>
> > >     <name>luks1.img</name>
> > >     <capacity unit='G'>1</capacity>
> > >     <target>
> > >         <path>/var/lib/libvirt/images/luks/luks1.img</path>
> > >         <format type='raw'/>
> > >         <encryption format='luks'>
> > >             <secret type='passphrase'
> > > uuid='f981dd17-143f-45bc-88e6-ed1fe20ce9da'/>
> > >             <cipher name='cast5' size='128' mode='xts' hash='md5'/>
> > >             <ivgen name='essiv' hash='md5'/>
> > >         </encryption>
> > >     </target>
> > > </volume>
> > > 
> > > Running: virsh vol-create luks /tmp/luks_vol.xml
> > > error: Failed to create vol from /tmp/luks_vol.xml
> > > error: internal error: Child process (/usr/bin/qemu-img create -f luks
> > > --object
> > > secret,id=luks1.img_luks0,file=/var/run/libvirt/storage/luks.luks1.img.
> > > secret.eaTuyc -o
> > > key-secret=luks1.img_luks0,cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5,
> > > ivgen-alg=essiv,ivgen-hash-alg=md5 /var/lib/libvirt/images/luks/luks1.img
> > > 1048576K) unexpected fatal signal 11
> > 
> > Yep, seeing a signal 11 is always a bug. I'll investigate this
> 
> I'm unable to reproduce that crash. Can you provide information about what
> version of QEMU you saw this with, what OS platform, etc. Also could you
> capture a stack trace with GDB

qemu versions:
qemu-img-rhev-2.6.0-22.el7.x86_64
qemu-kvm-rhev-2.6.0-22.el7.x86_64

libvirt version:
libvirt-2.0.0-6.el7.x86_64

I tried with pure qemu-img cmd and it's not reproducible. Only reproducible with virsh command mentioned in comment 7. 

Got gdb bt as follow (and coredump attached as attachment 1193155 [details]):
Thread 1 (Thread 0x7ffff7fc6a40 (LWP 27602)):
#0  qcrypto_cipher_encrypt (cipher=0xd2ff8da21cd30e09, in=in@entry=0x5555564b0170, out=out@entry=0x5555564b0170, len=len@entry=8, 
    errp=errp@entry=0x55555661bf90) at crypto/cipher-gcrypt.c:255
        ctx = <optimized out>
        err = <optimized out>
        __func__ = "qcrypto_cipher_encrypt"
#1  0x00005555555d4a30 in qcrypto_ivgen_essiv_calculate (ivgen=<optimized out>, sector=1, iv=0x5555564b0168 "\227Րd\240\033\002o\001", niv=8, 
    errp=0x55555661bf90) at crypto/ivgen-essiv.c:86
        essiv = 0x5555564b0160
        ndata = 8
        data = 0x5555564b0170 "\001"
#2  0x00005555555d5997 in qcrypto_block_encrypt_helper (cipher=cipher@entry=0x555556488120, niv=8, ivgen=ivgen@entry=0x555556501480, 
    sectorsize=sectorsize@entry=512, startsector=1, startsector@entry=0, 
    buf=0x555556628200 "\307ʭ.\005\215S\340c\t\364\r\314Ƙ[\302\006P\214\200\237\313f\315\030ZW\253a\365,I\220zs!\260\024\\Ʉ\376\354\313VL\257X\362\307O2vt\345\371Cb\024n\374\006\247\377^%q\220-\370\n\217\342$\251\222\360\331\365\036\302\200DZ\271\260\350p\316Qu|\372p+\331t\350\355\017\a\v~H\324AC%\314\327A$\331\327ָϛ3\212\tH\251qPNR\f\201\323\025\071\340\060n\236\316\024\360C\231X\340a\255u昒ϋ[p\333\340=9\235\221\375?\343h\373. ӎ\214\315`H3߳E@A8\257|\034\226\262\355\324!\251\177\231\024\362\022m\324\325\324\024\264"..., 
    buf@entry=0x555556628000 "Hj\223\235\210\035\324e\206z+\211+\360H\021<Cj߈\245\376\315Y\323r\225\065j\370S\224\276\061\006\250.\375\337\\\244BI\242\350\036\215\313\366\342\313\362\235\360hρ}j=\v\321N\t\270\322\177\rrj\243\356\260\063B*\224\037\242X \bۉr+\001ZPB\242\027\241\366\016\017\317I\276\017\223\250X\f,\222\225\030\275\372\071\f\035\020B\375I\v0\233(B\361\355e\035\246\307\320WZ\217U\235-o\211\064Μ\210ч\264\067\031\v\370ی\211[\326\376\372\341\235\016&kv\334\\\360\037χ\217\067\275", <incomplete sequence \354>, len=127488, len@entry=128000, errp=errp@entry=0x55555661bf90)
    at crypto/block.c:232
        nbytes = <optimized out>
        iv = 0x5555564b0168 "\227Րd\240\033\002o\001"
        ret = -1
#3  0x00005555555d65b9 in qcrypto_block_luks_create (block=0x555556490a80, options=<optimized out>, 
    initfunc=0x5555555c1640 <block_crypto_init_func>, writefunc=0x5555555c15e0 <block_crypto_write_func>, opaque=0x55555661bf30, errp=0x55555661bf90)
    at crypto/block-luks.c:1167
        luks = 0x55555661c000
        luks_opts = {has_key_secret = true, key_secret = 0x55555648a0a0 "luks1.img_luks0", has_cipher_alg = true, 
          cipher_alg = QCRYPTO_CIPHER_ALG_CAST5_128, has_cipher_mode = true, cipher_mode = QCRYPTO_CIPHER_MODE_XTS, has_ivgen_alg = true, 
          ivgen_alg = QCRYPTO_IVGEN_ALG_ESSIV, has_ivgen_hash_alg = true, ivgen_hash_alg = QCRYPTO_HASH_ALG_MD5, has_hash_alg = true, 
          hash_alg = QCRYPTO_HASH_ALG_MD5}
        local_err = 0x0
        masterkey = 0x555556501200 "\267\215\031\263\202\243\006%o\222Y\326-\323au\240\325\371\260.>\261\032\357\023m\005\270S\242M@\022PVUU"
        slotkey = 0x555556501300 ",\207\345\027Y\200\253R\376$z\373g\356[\220ljS\346\027\356\223\340v\017gP\021ƶ\272`~\207UUU"
        splitkey = 0x555556628000 "Hj\223\235\210\035\324e\206z+\211+\360H\021<Cj߈\245\376\315Y\323r\225\065j\370S\224\276\061\006\250.\375\337\\\244BI\242\350\036\215\313\366\342\313\362\235\360hρ}j=\v\321N\t\270\322\177\rrj\243\356\260\063B*\224\037\242X \bۉr+\001ZPB\242\027\241\366\016\017\317I\276\017\223\250X\f,\222\225\030\275\372\071\f\035\020B\375I\v0\233(B\361\355e\035\246\307\320WZ\217U\235-o\211\064Μ\210ч\264\067\031\v\370ی\211[\326\376\372\341\235\016&kv\334\\\360\037χ\217\067\275", <incomplete sequence \354>
        splitkeylen = 128000
        i = <optimized out>
        cipher = 0x555556488120
        ivgen = 0x555556501480
        password = 0x5555564b0080 "redhat"
        cipher_mode = <optimized out>
        ivgen_alg = <optimized out>
        ivgen_hash_alg = <optimized out>
        hash_alg = <optimized out>
        cipher_mode_spec = 0x555556488100 "xts-essiv:md5"
        ivcipheralg = QCRYPTO_CIPHER_ALG_CAST5_128
        __func__ = "qcrypto_block_luks_create"
#4  0x00005555555d5703 in qcrypto_block_create (options=options@entry=0x555556490280, 
    initfunc=initfunc@entry=0x5555555c1640 <block_crypto_init_func>, writefunc=writefunc@entry=0x5555555c15e0 <block_crypto_write_func>, 
    opaque=opaque@entry=0x55555661bf30, errp=errp@entry=0x55555661bf90) at crypto/block.c:98
        block = 0x555556490a80
        __func__ = "qcrypto_block_create"
#5  0x00005555555c18cc in block_crypto_create_generic (format=Q_CRYPTO_BLOCK_FORMAT_LUKS, errp=0x55555661bf90, opts=<optimized out>, 
    filename=<optimized out>) at block/crypto.c:353
        ret = -22
        create_opts = <optimized out>
        data = {filename = 0x55555648cc30 "/var/lib/libvirt/images/luks/luks1.img", opts = 0x5555564c0050, blk = 0x0, size = 1073741824}
        crypto = 0x0
#6  block_crypto_create_luks (filename=<optimized out>, opts=<optimized out>, errp=0x55555661bf90) at block/crypto.c:562
No locals.
#7  0x0000555555572d4a in bdrv_create_co_entry (opaque=0x7fffffffdff0) at block.c:313
        local_err = 0x0
        ret = <optimized out>
        cco = 0x7fffffffdff0
#8  0x000055555561f15a in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:78
        self = 0x5555564bc120
        co = 0x5555564bc120
#9  0x00007ffff3063110 in ?? () from /lib64/libc.so.6
No symbol table info available.
Comment 14 Daniel Berrange 2016-08-23 18:06:10 EDT
(In reply to yisun from comment #13)
> (In reply to Daniel Berrange from comment #11)
> > (In reply to Daniel Berrange from comment #9)
> > > > 3. (THIS MAYBE A BUG) when
> > > > cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5(/sha1/sha256, this value
> > > > doesn't matter),ivgen-alg=essiv,ivgen-hash-alg=md5 there will be a
> > > > "unexpected fatal signal 11"
> > > > 
> > > > # cat /tmp/luks_vol.xml
> > > > <volume>
> > > >     <name>luks1.img</name>
> > > >     <capacity unit='G'>1</capacity>
> > > >     <target>
> > > >         <path>/var/lib/libvirt/images/luks/luks1.img</path>
> > > >         <format type='raw'/>
> > > >         <encryption format='luks'>
> > > >             <secret type='passphrase'
> > > > uuid='f981dd17-143f-45bc-88e6-ed1fe20ce9da'/>
> > > >             <cipher name='cast5' size='128' mode='xts' hash='md5'/>
> > > >             <ivgen name='essiv' hash='md5'/>
> > > >         </encryption>
> > > >     </target>
> > > > </volume>
> > > > 
> > > > Running: virsh vol-create luks /tmp/luks_vol.xml
> > > > error: Failed to create vol from /tmp/luks_vol.xml
> > > > error: internal error: Child process (/usr/bin/qemu-img create -f luks
> > > > --object
> > > > secret,id=luks1.img_luks0,file=/var/run/libvirt/storage/luks.luks1.img.
> > > > secret.eaTuyc -o
> > > > key-secret=luks1.img_luks0,cipher-alg=cast5-128,cipher-mode=xts,hash-alg=md5,
> > > > ivgen-alg=essiv,ivgen-hash-alg=md5 /var/lib/libvirt/images/luks/luks1.img
> > > > 1048576K) unexpected fatal signal 11
> > > 
> > > Yep, seeing a signal 11 is always a bug. I'll investigate this
> > 
> > I'm unable to reproduce that crash. Can you provide information about what
> > version of QEMU you saw this with, what OS platform, etc. Also could you
> > capture a stack trace with GDB
> 
> qemu versions:
> qemu-img-rhev-2.6.0-22.el7.x86_64
> qemu-kvm-rhev-2.6.0-22.el7.x86_64
> 
> libvirt version:
> libvirt-2.0.0-6.el7.x86_64
> 
> I tried with pure qemu-img cmd and it's not reproducible. Only reproducible
> with virsh command mentioned in comment 7. 

Thanks, I've reproduced it now and figured out theproblem

cast5-128 with xts is not a valid combination, since the former has a 8 byte blocksize, while xts mandates a 16 byte block size. Thus we were writing beyond the end of a buffer, causing memory corruption. We should report an error immediately for this invalid combination of xts + cast5-128 - the same applies to xts + aes-128, or any other -128 or -160 cipher - only -256 ciphers are permitted with xts.

IOW, we should fix the bug in QEMU, and for your testing you should check that you see a nice error message for this combination - you shouldn't expect it to succeed.

In debugging this, I also noticed the qemu is mistakenly built against gcrypt instead of nettle, so we must fix that too
Comment 15 yangyang 2016-08-29 03:14:35 EDT
Hi,

I made an attempt to create luks image on AMD host but failed. And it reports an error as follows. I have no idea why it failed on this platform.

qemu-img: /var/lib/libvirt/images/luks.img: Unable to generate uuids on this platform

# virsh secret-list
 UUID                                  Usage
--------------------------------------------------------------------------------
 2ee92d96-c090-457a-8012-e22a7821235c  ceph client.ceph
 d0d5ded3-1647-4e35-b954-31c157c2fa0d  volume luks.secret

# cat vol-luks.xml 
<volume>
  <name>luks.img</name>
  <source>
  </source>
  <capacity unit="G">1</capacity>
  <target>
    <format type='raw'/>
    <encryption format='luks'>
      <secret type='passphrase' usage='luks.secret'/>
    </encryption>
  </target>
</volume>

# virsh vol-create  default vol-luks.xml 
error: Failed to create vol from vol-luks.xml
error: internal error: Child process (/usr/local/bin/qemu-img create -f luks --object secret,id=luks.img_luks0,file=/var/run/libvirt/storage/default.luks.img.secret.4itYUR -o key-secret=luks.img_luks0 /var/lib/libvirt/images/luks.img 1048576K) unexpected exit status 1: 2016-08-29 05:19:52.223+0000: 28127: debug : virFileClose:102 : Closed fd 28
2016-08-29 05:19:52.223+0000: 28127: debug : virFileClose:102 : Closed fd 30
2016-08-29 05:19:52.223+0000: 28127: debug : virFileClose:102 : Closed fd 26
qemu-img: /var/lib/libvirt/images/luks.img: Unable to generate uuids on this platform
Comment 16 yangyang 2016-08-29 03:16 EDT
Created attachment 1195188 [details]
virsh capabilities

Added output of virsh capabilities
Comment 17 Daniel Berrange 2016-09-05 05:56:02 EDT
(In reply to yangyang from comment #15)
> Hi,
> 
> I made an attempt to create luks image on AMD host but failed. And it
> reports an error as follows. I have no idea why it failed on this platform.
> 
> qemu-img: /var/lib/libvirt/images/luks.img: Unable to generate uuids on this
> platform

This message says it is missing libuuid.so but the official RPM builds include this. 

Did you build qemu yourself ?
Comment 18 yangyang 2016-09-05 06:30:20 EDT
(In reply to Daniel Berrange from comment #17)
> (In reply to yangyang from comment #15)
> > Hi,
> > 
> > I made an attempt to create luks image on AMD host but failed. And it
> > reports an error as follows. I have no idea why it failed on this platform.
> > 
> > qemu-img: /var/lib/libvirt/images/luks.img: Unable to generate uuids on this
> > platform
> 
> This message says it is missing libuuid.so but the official RPM builds
> include this. 
> 
> Did you build qemu yourself ?

No. I uses the official qemu build qemu-kvm-rhev-2.6.0-22.el7.x86_64
Comment 20 Miroslav Rezanina 2016-09-09 07:25:04 EDT
Fix included in qemu-kvm-rhev-2.6.0-24.el7
Comment 22 yisun 2016-09-14 02:09:33 EDT
 Comment 18 yangyang 2016-09-05 06:30:20 EDT has some questions not confirmed yet, thx.
Comment 23 Daniel Berrange 2016-09-14 05:14:53 EDT
Please re-test with the newer build qemu-kvm-rhev-2.6.0-24.el7 which has switched to using nettle instead of gcrypt
Comment 26 Daniel Berrange 2016-09-19 04:43:49 EDT
You've installed a duplicate version of QEMU in /usr/local that is clashing with the RPM installed version and missing functionality of the proper RPM install. So all testing you've done in this particular host is invalid, as its potentially using the wrong QEMU.
Comment 27 juzhang 2016-09-19 21:35:33 EDT
(In reply to Daniel Berrange from comment #26)
> You've installed a duplicate version of QEMU in /usr/local that is clashing
> with the RPM installed version and missing functionality of the proper RPM
> install. So all testing you've done in this particular host is invalid, as
> its potentially using the wrong QEMU.

Hi Yangyang,

Could you have a look?

Best Regards,
Junyi
Comment 28 yangyang 2016-09-19 22:00:54 EDT
Daniel and Junyi

I apologize for the duplicate QEMU in my host and thank you. Re-tested it after removing self-build QEMU. The problem is not reproduced

Thanks
Comment 30 pingl 2016-09-21 02:16:29 EDT
Hi Daniel,

I have tested luks as comment 29 described. Could you help to confirm below questions?

1. Is it enough to verify this bz? If not, could you help to share some suggestion for verification?
2. If there is something wrong in the comment 29, please help to correct it.

Thanks in advance.
Comment 34 pingl 2016-09-22 02:27:22 EDT
Hi Daniel, 

I tested qemu-iotests both in upstream and redhat repo. But the results are different from what you shared. Coudld you help to check it? For detailed result, you can refer the attachment.
Seems redhat repo doesn't support to test luks format, as there is no "-luks" option in tests/qemu-iotests/common.

upstream repo:
    git://git.qemu.org/qemu.git
redhat repo:
    git://git.app.eng.bos.redhat.com/virt/rhel7/qemu-kvm.git

Steps of qemu-iotests for luks:
    #git clone git://git.qemu.org/qemu.git
    #cd qemu
    #yum install zlib* glib* -y
    #git submodule update --init pixman
    #git submodule update --init dtc
    #./configure
    #cd tests/qemu-iotests/
    #export QEMU_PROG=/usr/libexec/qemu-kvm
    #./check -luks

Passed: 001 002 003 004 005 008 009 010 011 012 021 032 048 052 143 149
Not run: 007 013 014 015 017 018 019 020 022 023 024 025 026 027 028 029 030 031 034 035 036 037 038 039 040 041 042 043 044 045 046 047 049 050 051 053 054 055 056 057 058 059 060 061 062 063 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 093 094 095 096 097 098 099 101 102 103 104 105 107 108 109 110 111 112 113 114 115 116 117 118 119 121 122 123 124 128 129 130 131 132 133 134 135 136 137 138 139 141 142 144 146 148 150 152 154 155 156
Failures: 033 120 140 145 157 162
Failed 6 of 22 tests
Comment 35 pingl 2016-09-22 02:30 EDT
Created attachment 1203602 [details]
result for qemu-iotests of luks format
Comment 36 Daniel Berrange 2016-09-22 03:56:45 EDT
Oh, my mistake. I forgot that the iotest support was not added until QEMU 2.7, so we can't test it in RHEL-7.3 version of QEMU 2.6. So just ignore the iotests suggestion.
Comment 37 pingl 2016-09-22 04:11:55 EDT
(In reply to Daniel Berrange from comment #36)
> Oh, my mistake. I forgot that the iotest support was not added until QEMU
> 2.7, so we can't test it in RHEL-7.3 version of QEMU 2.6. So just ignore the
> iotests suggestion.

Yes. I checked the tag in upstream repo, the latest tag is v2.7.0-rc5. Maybe that is why I can test luks format in upstream repo.

Above all, may i set this BZ as verified?
Comment 38 Daniel Berrange 2016-09-22 04:18:01 EDT
(In reply to pingl from comment #37)
> Above all, may i set this BZ as verified?

Yep, that's ok
Comment 39 pingl 2016-09-22 04:23:59 EDT
(In reply to Daniel Berrange from comment #38)
> (In reply to pingl from comment #37)
> > Above all, may i set this BZ as verified?
> 
> Yep, that's ok

@Daniel Appreciate for kindly help. 

Set this BZ as verified.
Comment 41 errata-xmlrpc 2016-11-07 15:56:54 EST
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://rhn.redhat.com/errata/RHBA-2016-2673.html

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