In the updated HW-wrapped key code in the android14 kernels, HW-wrapped
keys are only allowed on a multi-block-device filesystem if they have a
compatible HW-wrapped keys implementation. While in principle this is a
good thing to check, my implementation of it, which simply checks
whether the block devices have the same crypto profiles, doesn't work
when device-mapper is being used.
To actually do that check correctly, I think we'd need to add a
HW-wrapped keys implementation name or ID to the crypto capabilities.
That being said, in Android the HW-wrapped keys implementation is a
global thing anyway. So in the interest of not overcomplicating things,
for now let's just drop these extra checks that are causing problems.
Bug: 160883801
Bug: 265180564
Fixes: 4887dd4fe3 ("ANDROID: fscrypt: add support for hardware-wrapped keys")
Fixes: 3918b39c3e ("ANDROID: update "block: add basic hardware-wrapped key support" to v7")
Change-Id: Ia49d62cc2c56447fb898f19bf67df1a38af379f8
Signed-off-by: Eric Biggers <ebiggers@google.com>
The hardware-wrapped key support in this branch is based on my patch
"[RFC PATCH v3 1/3] block: add basic hardware-wrapped key support"
(https://lore.kernel.org/all/20211021181608.54127-2-ebiggers@kernel.org).
I've since made several updates to that patch and it is now at v7.
This commit brings in the updates from v3 to v7. The main change is
making blk_crypto_derive_sw_secret() operate on a struct block_device,
and adding blk_crypto_hw_wrapped_keys_compatible(). This aligns with
changes upstream in v6.1 and v6.2 that removed block-layer internal
structures from the API that blk-crypto exposes to upper layers.
There's also a slight change in prototype for ->derive_sw_secret, so a
couple out-of-tree drivers will need to be updated, but people
maintaining out-of-tree drivers know what they are dealing with anyway.
Bug: 160883801
Link: https://lore.kernel.org/r/20221216203636.81491-2-ebiggers@kernel.org
Change-Id: I0f285c11c2764064cd4a9d6eac0089099a9601ed
Signed-off-by: Eric Biggers <ebiggers@google.com>
Update the device-mapper core to support exposing the inline crypto
support of wrapped keys through the device-mapper device.
derive_sw_secret in keyslot manager is used to derive the software
secret from the given wrapped keyblob using the underlying blk device.
Given that the sw_secret is the same for a given wrapped keyblob the
call exits when the first underlying blk-device suceeds.
This is a reworked version of a patch which was temporily reverted by
https://android-review.googlesource.com/c/kernel/common/+/1867366, and
which originated from
https://android-review.googlesource.com/c/kernel/common/+/1229460.
Bug: 147209885
Bug: 160883266
Bug: 160883801
Test: Validated FBE with wrappedkey_v0 when /data is mounted on a
dm device.
Change-Id: Id30d00afdbd3114e089887db1493ffd41e833e21
Signed-off-by: Barani Muthukumaran <bmuthuku@codeaurora.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit fd35c92fc41db1858b2197d8a3987125fd18abfa)
To prevent keys from being compromised if an attacker acquires read
access to kernel memory, some inline encryption hardware can accept keys
which are wrapped by a per-boot hardware-internal key. This avoids
needing to keep the plaintext keys in kernel memory, without restricting
the number of keys that can be used. Such keys can be initially
generated either by software (in which case they must be imported to
hardware to be wrapped) or directly by the hardware. There is also a
mechanism to derive a "software secret" for cryptographic tasks that
can't be handled by inline encryption.
To support this hardware, allow struct blk_crypto_key to represent a
hardware-wrapped key as an alternative to a standard key, and make
drivers set flags in struct blk_crypto_profile to indicate which types
of keys they support. Also add the derive_sw_secret() low-level
operation, which drivers supporting wrapped keys must implement.
For more information, see the detailed documentation which this patch
adds to Documentation/block/inline-encryption.rst.
This is a reworked version of a patch which was temporily reverted by
https://android-review.googlesource.com/c/kernel/common/+/1867367, and
which originated from several ANDROID patches that were consolidated by
https://android-review.googlesource.com/c/kernel/common-patches/+/1350782.
This version of the patch matches the patch in the below "Link:" tag
that was sent upstream as an RFC. However, due to its history as
ANDROID, it remains tagged as ANDROID rather than FROMLIST.
Bug: 160883801
Link: https://lore.kernel.org/r/20211021181608.54127-2-ebiggers@kernel.org
Change-Id: I4d18c261c279d606457b33374234c0a037e1d45a
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit c26f08d1d450b51a2b5f83087daae7ffc68aa2db)
This function is trivial and is only used in one place. Having this
function is misleading because it implies that blk_crypto_register()
needs to be paired with blk_crypto_unregister(), which is not the case.
Just set disk->queue->crypto_profile to NULL directly.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20211124013733.347612-1-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 72cd9df2ef788d88c138d51223a01ca6281f232d)
Change-Id: Icf215db41f6b1cdc377f925b8150a47d62db18b8
blk_keyslot_manager is misnamed because it doesn't necessarily manage
keyslots. It actually does several different things:
- Contains the crypto capabilities of the device.
- Provides functions to control the inline encryption hardware.
Originally these were just for programming/evicting keyslots;
however, new functionality (hardware-wrapped keys) will require new
functions here which are unrelated to keyslots. Moreover,
device-mapper devices already (ab)use "keyslot_evict" to pass key
eviction requests to their underlying devices even though
device-mapper devices don't have any keyslots themselves (so it
really should be "evict_key", not "keyslot_evict").
- Sometimes (but not always!) it manages keyslots. Originally it
always did, but device-mapper devices don't have keyslots
themselves, so they use a "passthrough keyslot manager" which
doesn't actually manage keyslots. This hack works, but the
terminology is unnatural. Also, some hardware doesn't have keyslots
and thus also uses a "passthrough keyslot manager" (support for such
hardware is yet to be upstreamed, but it will happen eventually).
Let's stop having keyslot managers which don't actually manage keyslots.
Instead, rename blk_keyslot_manager to blk_crypto_profile.
This is a fairly big change, since for consistency it also has to update
keyslot manager-related function names, variable names, and comments --
not just the actual struct name. However it's still a fairly
straightforward change, as it doesn't change any actual functionality.
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit cb77cb5abe1f4fae4a33b735606aae22f9eaa1c7)
Conflicts:
block/blk-crypto.c
drivers/scsi/ufs/ufshcd-crypto.c
include/linux/blk-mq.h
Bug: 160883801
Bug: 162257402
Bug: 207390665
Bug: 234653003
Change-Id: I787cdc0d74baf5e4c94d73d5c467122bcc472649
Signed-off-by: Eric Biggers <ebiggers@google.com>
In preparation for renaming struct blk_keyslot_manager to struct
blk_crypto_profile, rename the keyslot-manager.h and keyslot-manager.c
source files. Renaming these files separately before making a lot of
changes to their contents makes it easier for git to understand that
they were renamed.
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-3-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 1e8d44bddf57f6d878e083f281a34d5c88feb7db)
Bug: 160883801
Bug: 162257402
Bug: 207390665
Bug: 234653003
Change-Id: I19c9033d2dee2cc41a9274448d4d99f4d22dce89
Signed-off-by: Eric Biggers <ebiggers@google.com>
