Skip to content
  • Maxim Levitsky's avatar
    bbfdae91
    block/crypto: implement the encryption key management · bbfdae91
    Maxim Levitsky authored
    
    
    This implements the encryption key management using the generic code in
    qcrypto layer and exposes it to the user via qemu-img
    
    This code adds another 'write_func' because the initialization
    write_func works directly on the underlying file, and amend
    works on instance of luks device.
    
    This commit also adds a 'hack/workaround' I and Kevin Wolf (thanks)
    made to make the driver both support write sharing (to avoid breaking the users),
    and be safe against concurrent  metadata update (the keyslots)
    
    Eventually the write sharing for luks driver will be deprecated
    and removed together with this hack.
    
    The hack is that we ask (as a format driver) for BLK_PERM_CONSISTENT_READ
    and then when we want to update the keys, we unshare that permission.
    So if someone else has the image open, even readonly, encryption
    key update will fail gracefully.
    
    Also thanks to Daniel Berrange for the idea of
    unsharing read, rather that write permission which allows
    to avoid cases when the other user had opened the image read-only.
    
    Signed-off-by: default avatarMaxim Levitsky <mlevitsk@redhat.com>
    Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
    Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
    Message-Id: <20200608094030.670121-8-mlevitsk@redhat.com>
    Signed-off-by: default avatarMax Reitz <mreitz@redhat.com>
    bbfdae91
    block/crypto: implement the encryption key management
    Maxim Levitsky authored
    
    
    This implements the encryption key management using the generic code in
    qcrypto layer and exposes it to the user via qemu-img
    
    This code adds another 'write_func' because the initialization
    write_func works directly on the underlying file, and amend
    works on instance of luks device.
    
    This commit also adds a 'hack/workaround' I and Kevin Wolf (thanks)
    made to make the driver both support write sharing (to avoid breaking the users),
    and be safe against concurrent  metadata update (the keyslots)
    
    Eventually the write sharing for luks driver will be deprecated
    and removed together with this hack.
    
    The hack is that we ask (as a format driver) for BLK_PERM_CONSISTENT_READ
    and then when we want to update the keys, we unshare that permission.
    So if someone else has the image open, even readonly, encryption
    key update will fail gracefully.
    
    Also thanks to Daniel Berrange for the idea of
    unsharing read, rather that write permission which allows
    to avoid cases when the other user had opened the image read-only.
    
    Signed-off-by: default avatarMaxim Levitsky <mlevitsk@redhat.com>
    Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
    Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
    Message-Id: <20200608094030.670121-8-mlevitsk@redhat.com>
    Signed-off-by: default avatarMax Reitz <mreitz@redhat.com>
Loading