| Message ID | 20190814202219.1870-11-mlevitsk@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | RFC: luks/encrypted qcow2 key management | expand |
On Wed, Aug 14, 2019 at 11:22:16PM +0300, Maxim Levitsky wrote: > This implements the encryption key management > using the generic code in qcrypto layer > > This code adds another 'write_func' because the initialization > write_func works directly on the underlying file, > because during the creation, there is no open instance > of the luks driver, but during regular use, we have it, > and should use it instead. > > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> > --- > block/crypto.c | 96 ++++++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 93 insertions(+), 3 deletions(-) > > diff --git a/block/crypto.c b/block/crypto.c > index 42a3f0898b..415b6db041 100644 > --- a/block/crypto.c > +++ b/block/crypto.c > @@ -36,6 +36,7 @@ typedef struct BlockCrypto BlockCrypto; > > struct BlockCrypto { > QCryptoBlock *block; > + bool updating_keys; > }; > > > @@ -69,6 +70,24 @@ static ssize_t block_crypto_read_func(QCryptoBlock *block, > return ret; > } > > +static ssize_t block_crypto_write_func(QCryptoBlock *block, > + size_t offset, > + const uint8_t *buf, > + size_t buflen, > + void *opaque, > + Error **errp) > +{ > + BlockDriverState *bs = opaque; > + ssize_t ret; > + > + ret = bdrv_pwrite(bs->file, offset, buf, buflen); > + if (ret < 0) { > + error_setg_errno(errp, -ret, "Could not write encryption header"); > + return ret; > + } > + return ret; > +} > + > > struct BlockCryptoCreateData { > BlockBackend *blk; > @@ -622,6 +641,78 @@ block_crypto_get_specific_info_luks(BlockDriverState *bs, Error **errp) > return spec_info; > } > > + > +static int > +block_crypto_setup_encryption(BlockDriverState *bs, > + enum BlkSetupEncryptionAction action, > + QCryptoEncryptionSetupOptions *options, > + bool force, > + Error **errp) > +{ > + BlockCrypto *crypto = bs->opaque; > + int ret; > + > + assert(crypto); > + assert(crypto->block); > + > + crypto->updating_keys = true; > + > + ret = bdrv_child_refresh_perms(bs, bs->file, errp); > + > + if (ret) { > + crypto->updating_keys = false; > + return ret; > + } > + > + ret = qcrypto_block_setup_encryption(crypto->block, > + block_crypto_read_func, > + block_crypto_write_func, > + bs, > + action, > + options, > + force, > + errp); > + > + crypto->updating_keys = false; > + bdrv_child_refresh_perms(bs, bs->file, errp); > + > + > + return ret; > + > +} > + > + > +static void > +block_crypto_child_perms(BlockDriverState *bs, BdrvChild *c, > + const BdrvChildRole *role, > + BlockReopenQueue *reopen_queue, > + uint64_t perm, uint64_t shared, > + uint64_t *nperm, uint64_t *nshared) > +{ > + > + BlockCrypto *crypto = bs->opaque; > + > + /* > + * This driver doesn't modify LUKS metadata except > + * when updating the encryption slots. > + * Allow share-rw=on as a special case. > + * > + * Encryption update will set the crypto->updating_keys > + * during that period and refresh permissions > + * > + * */ > + > + if (crypto->updating_keys) { > + /*need exclusive write access for header update */ > + perm |= BLK_PERM_WRITE; > + shared &= ~BLK_PERM_WRITE; > + } So if 2 QEMU's have the same LUKS image open, this means that if one tries to update the header, it will fail to upgrade its lock & thus be blocked from updating header ? > + > + bdrv_filter_default_perms(bs, c, role, reopen_queue, > + perm, shared, nperm, nshared); > +} Regards, Daniel
On Thu, 2019-08-22 at 12:29 +0100, Daniel P. Berrangé wrote: > On Wed, Aug 14, 2019 at 11:22:16PM +0300, Maxim Levitsky wrote: > > This implements the encryption key management > > using the generic code in qcrypto layer > > > > This code adds another 'write_func' because the initialization > > write_func works directly on the underlying file, > > because during the creation, there is no open instance > > of the luks driver, but during regular use, we have it, > > and should use it instead. > > > > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> > > --- > > block/crypto.c | 96 ++++++++++++++++++++++++++++++++++++++++++++++++-- > > 1 file changed, 93 insertions(+), 3 deletions(-) > > > > diff --git a/block/crypto.c b/block/crypto.c > > index 42a3f0898b..415b6db041 100644 > > --- a/block/crypto.c > > +++ b/block/crypto.c > > @@ -36,6 +36,7 @@ typedef struct BlockCrypto BlockCrypto; > > > > struct BlockCrypto { > > QCryptoBlock *block; > > + bool updating_keys; > > }; > > > > > > @@ -69,6 +70,24 @@ static ssize_t block_crypto_read_func(QCryptoBlock *block, > > return ret; > > } > > > > +static ssize_t block_crypto_write_func(QCryptoBlock *block, > > + size_t offset, > > + const uint8_t *buf, > > + size_t buflen, > > + void *opaque, > > + Error **errp) > > +{ > > + BlockDriverState *bs = opaque; > > + ssize_t ret; > > + > > + ret = bdrv_pwrite(bs->file, offset, buf, buflen); > > + if (ret < 0) { > > + error_setg_errno(errp, -ret, "Could not write encryption header"); > > + return ret; > > + } > > + return ret; > > +} > > + > > > > struct BlockCryptoCreateData { > > BlockBackend *blk; > > @@ -622,6 +641,78 @@ block_crypto_get_specific_info_luks(BlockDriverState *bs, Error **errp) > > return spec_info; > > } > > > > + > > +static int > > +block_crypto_setup_encryption(BlockDriverState *bs, > > + enum BlkSetupEncryptionAction action, > > + QCryptoEncryptionSetupOptions *options, > > + bool force, > > + Error **errp) > > +{ > > + BlockCrypto *crypto = bs->opaque; > > + int ret; > > + > > + assert(crypto); > > + assert(crypto->block); > > + > > + crypto->updating_keys = true; > > + > > + ret = bdrv_child_refresh_perms(bs, bs->file, errp); > > + > > + if (ret) { > > + crypto->updating_keys = false; > > + return ret; > > + } > > + > > + ret = qcrypto_block_setup_encryption(crypto->block, > > + block_crypto_read_func, > > + block_crypto_write_func, > > + bs, > > + action, > > + options, > > + force, > > + errp); > > + > > + crypto->updating_keys = false; > > + bdrv_child_refresh_perms(bs, bs->file, errp); > > + > > + > > + return ret; > > + > > +} > > + > > + > > +static void > > +block_crypto_child_perms(BlockDriverState *bs, BdrvChild *c, > > + const BdrvChildRole *role, > > + BlockReopenQueue *reopen_queue, > > + uint64_t perm, uint64_t shared, > > + uint64_t *nperm, uint64_t *nshared) > > +{ > > + > > + BlockCrypto *crypto = bs->opaque; > > + > > + /* > > + * This driver doesn't modify LUKS metadata except > > + * when updating the encryption slots. > > + * Allow share-rw=on as a special case. > > + * > > + * Encryption update will set the crypto->updating_keys > > + * during that period and refresh permissions > > + * > > + * */ > > + > > + if (crypto->updating_keys) { > > + /*need exclusive write access for header update */ > > + perm |= BLK_PERM_WRITE; > > + shared &= ~BLK_PERM_WRITE; > > + } > > So if 2 QEMU's have the same LUKS image open, this means that > if one tries to update the header, it will fail to upgrade > its lock & thus be blocked from updating header ? > I guess so. That what I understood from our talk with Kevin and then also from my own understanding of the permission code. I absolutely don't like the 'global' variable 'crypto->updating_keys' but we kind of agreed that this must be done like that. In the defense of this, this code is only needed for backward compatibility, so maybe this is the right solution after all. > > + > > + bdrv_filter_default_perms(bs, c, role, reopen_queue, > > + perm, shared, nperm, nshared); > > Best regards, Maxim Levitsky
diff --git a/block/crypto.c b/block/crypto.c index 42a3f0898b..415b6db041 100644 --- a/block/crypto.c +++ b/block/crypto.c @@ -36,6 +36,7 @@ typedef struct BlockCrypto BlockCrypto; struct BlockCrypto { QCryptoBlock *block; + bool updating_keys; }; @@ -69,6 +70,24 @@ static ssize_t block_crypto_read_func(QCryptoBlock *block, return ret; } +static ssize_t block_crypto_write_func(QCryptoBlock *block, + size_t offset, + const uint8_t *buf, + size_t buflen, + void *opaque, + Error **errp) +{ + BlockDriverState *bs = opaque; + ssize_t ret; + + ret = bdrv_pwrite(bs->file, offset, buf, buflen); + if (ret < 0) { + error_setg_errno(errp, -ret, "Could not write encryption header"); + return ret; + } + return ret; +} + struct BlockCryptoCreateData { BlockBackend *blk; @@ -622,6 +641,78 @@ block_crypto_get_specific_info_luks(BlockDriverState *bs, Error **errp) return spec_info; } + +static int +block_crypto_setup_encryption(BlockDriverState *bs, + enum BlkSetupEncryptionAction action, + QCryptoEncryptionSetupOptions *options, + bool force, + Error **errp) +{ + BlockCrypto *crypto = bs->opaque; + int ret; + + assert(crypto); + assert(crypto->block); + + crypto->updating_keys = true; + + ret = bdrv_child_refresh_perms(bs, bs->file, errp); + + if (ret) { + crypto->updating_keys = false; + return ret; + } + + ret = qcrypto_block_setup_encryption(crypto->block, + block_crypto_read_func, + block_crypto_write_func, + bs, + action, + options, + force, + errp); + + crypto->updating_keys = false; + bdrv_child_refresh_perms(bs, bs->file, errp); + + + return ret; + +} + + +static void +block_crypto_child_perms(BlockDriverState *bs, BdrvChild *c, + const BdrvChildRole *role, + BlockReopenQueue *reopen_queue, + uint64_t perm, uint64_t shared, + uint64_t *nperm, uint64_t *nshared) +{ + + BlockCrypto *crypto = bs->opaque; + + /* + * This driver doesn't modify LUKS metadata except + * when updating the encryption slots. + * Allow share-rw=on as a special case. + * + * Encryption update will set the crypto->updating_keys + * during that period and refresh permissions + * + * */ + + if (crypto->updating_keys) { + /*need exclusive write access for header update */ + perm |= BLK_PERM_WRITE; + shared &= ~BLK_PERM_WRITE; + } + + bdrv_filter_default_perms(bs, c, role, reopen_queue, + perm, shared, nperm, nshared); +} + + static const char *const block_crypto_strong_runtime_opts[] = { BLOCK_CRYPTO_OPT_LUKS_KEY_SECRET, @@ -634,9 +725,7 @@ static BlockDriver bdrv_crypto_luks = { .bdrv_probe = block_crypto_probe_luks, .bdrv_open = block_crypto_open_luks, .bdrv_close = block_crypto_close, - /* This driver doesn't modify LUKS metadata except when creating image. - * Allow share-rw=on as a special case. */ - .bdrv_child_perm = bdrv_filter_default_perms, + .bdrv_child_perm = block_crypto_child_perms, .bdrv_co_create = block_crypto_co_create_luks, .bdrv_co_create_opts = block_crypto_co_create_opts_luks, .bdrv_co_truncate = block_crypto_co_truncate, @@ -649,6 +738,7 @@ static BlockDriver bdrv_crypto_luks = { .bdrv_getlength = block_crypto_getlength, .bdrv_get_info = block_crypto_get_info_luks, .bdrv_get_specific_info = block_crypto_get_specific_info_luks, + .bdrv_setup_encryption = block_crypto_setup_encryption, .strong_runtime_opts = block_crypto_strong_runtime_opts, };
This implements the encryption key management using the generic code in qcrypto layer This code adds another 'write_func' because the initialization write_func works directly on the underlying file, because during the creation, there is no open instance of the luks driver, but during regular use, we have it, and should use it instead. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> --- block/crypto.c | 96 ++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 93 insertions(+), 3 deletions(-)