]> git.apps.os.sepia.ceph.com Git - ceph-ci.git/commit
librbd: don't decay LUKS{1,2}EncryptionFormat into LUKSEncryptionFormat
authorIlya Dryomov <idryomov@gmail.com>
Fri, 18 Nov 2022 13:53:24 +0000 (14:53 +0100)
committerIlya Dryomov <idryomov@gmail.com>
Sun, 4 Dec 2022 17:19:19 +0000 (18:19 +0100)
commit75acf7b6f5383fb6fbeeb0cdfe57da0638b8aab6
tree90ccea15a2c820ba50139ff26152094a9313e282
parent0230c1782e457a373aa6f1185ef3fb129afe8619
librbd: don't decay LUKS{1,2}EncryptionFormat into LUKSEncryptionFormat

Commit 9892ead7fcd9 ("librbd/crypto: allow loading luks format
without specifying version") introduced RBD_ENCRYPTION_FORMAT_LUKS
format identifier, matching cryptsetup's CRYPT_LUKS ("load any LUKS
version happens to be there").  However, in an effort to enable an
obscure "layered encryption with the same passphrase + old QEMU" use
case, it also introduced decaying of RBD_ENCRYPTION_FORMAT_LUKS1 and
RBD_ENCRYPTION_FORMAT_LUKS2 format identifiers, making it impossible
to assert on the format that is being loaded.  This new behavior was
then extended to standalone images.

Treating RBD_ENCRYPTION_FORMAT_LUKS1, RBD_ENCRYPTION_FORMAT_LUKS2
and RBD_ENCRYPTION_FORMAT_LUKS the same when loading encryption can
be construed as an opening for a format downgrade attack.  Let's
resurrect the previous standalone images behavior and extend it to
layered encryption instead.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
src/librbd/crypto/EncryptionFormat.h
src/librbd/crypto/luks/LUKSEncryptionFormat.cc
src/librbd/crypto/luks/LUKSEncryptionFormat.h
src/librbd/crypto/luks/LoadRequest.cc
src/librbd/crypto/luks/LoadRequest.h
src/test/librbd/crypto/luks/test_mock_LoadRequest.cc
src/test/librbd/test_librbd.cc