kernel/linux.git/block/blk-crypto.c, branch v7.2-rc2

Merge tag 'for-7.2/dm-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm

2026-06-16T07:50:54+00:00

Pull device mapper updates from Mikulas Patocka: - small cleanups in dm-vdo, dm-raid, dm-cache, dm-zoned-metadata - rework of dm-ima - introduce dm-inlinecrypt - fix wrong return value in dm-ioctl - fix rcu stall when polling * tag 'for-7.2/dm-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm-zoned-metadata: Use strscpy() to copy device name dm cache: make smq background work limit configurable dm-inlinecrypt: add support for hardware-wrapped keys dm: limit target bio polling to one shot dm-ioctl: report an error if a device has no table dm: add documentation for dm-inlinecrypt target dm-inlinecrypt: add target for inline block device encryption block: export blk-crypto symbols required by dm-inlinecrypt dm-ima: use active table's size if available dm-ima: Fail more gracefully in dm_ima_measure_on_* dm-ima: Handle race between rename and table swap dm-ima: Fix issues with dm_ima_measure_on_device_rename dm-ima: remove new_map from dm_ima_measure_on_device_clear dm-ima: Fix UAF errors and measuring incorrect context dm-ima: don't copy the active table to the inactive table dm-ima: Remove status_flags from dm_ima_measure_on_table_load() dm-ima: remove broken last_target_measured logic dm-ima: remove dm_ima_reset_data() dm-raid: only requeue bios when dm is suspending dm vdo: use get_random_u32() where appropriate

block: add a bio_endio_status helper

2026-05-28T13:59:18+00:00

Add a helper that sets bi_status and call bio_endio() as that is a very common pattern and convert the core block code over to it. Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Md Haris Iqbal Reviewed-by: Damien Le Moal Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260528084632.2505277-1-hch@lst.de Signed-off-by: Jens Axboe

block: export blk-crypto symbols required by dm-inlinecrypt

2026-05-06T15:41:29+00:00

bio_crypt_set_ctx(), blk_crypto_init_key(), and blk_crypto_start_using_key() are needed to use inline encryption; see Documentation/block/inline-encryption.rst. Export them so that dm-inlinecrypt can use them. The only reason these weren't exported before was that inline encryption was previously used only by fs/crypto/ which is built-in code. Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka

blk-crypto: handle the fallback above the block layer

2026-01-11T19:55:41+00:00

Add a blk_crypto_submit_bio helper that either submits the bio when it is not encrypted or inline encryption is provided, but otherwise handles the encryption before going down into the low-level driver. This reduces the risk from bio reordering and keeps memory allocation as high up in the stack as possible. Note that if the submitter knows that inline enctryption is known to be supported by the underyling driver, it can still use plain submit_bio. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Biggers Signed-off-by: Jens Axboe

blk-crypto: optimize data unit alignment checking

2026-01-11T19:55:41+00:00

Avoid the relatively high overhead of constructing and walking per-page segment bio_vecs for data unit alignment checking by merging the checks into existing loops. For hardware support crypto, perform the check in bio_split_io_at, which already contains a similar alignment check applied for all I/O. This means bio-based drivers that do not call bio_split_to_limits, should they ever grow blk-crypto support, need to implement the check themselves, just like all other queue limits checks. For blk-crypto-fallback do it in the encryption/decryption loops. This means alignment errors for decryption will only be detected after I/O has completed, but that seems like a worthwhile trade off. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Biggers Signed-off-by: Jens Axboe

blk-crypto: submit the encrypted bio in blk_crypto_fallback_bio_prep

2026-01-11T19:55:41+00:00

Restructure blk_crypto_fallback_bio_prep so that it always submits the encrypted bio instead of passing it back to the caller, which allows to simplify the calling conventions for blk_crypto_fallback_bio_prep and blk_crypto_bio_prep so that they never have to return a bio, and can use a true return value to indicate that the caller should submit the bio, and false that the blk-crypto code consumed it. The submission is handled by the on-stack bio list in the current task_struct by the block layer and does not cause additional stack usage or major overhead. It also prepares for the following optimization and fixes for the blk-crypto fallback write path. Signed-off-by: Christoph Hellwig Reviewed-by: Eric Biggers Signed-off-by: Jens Axboe

blk-crypto: use BLK_STS_INVAL for alignment errors

2025-10-30T14:52:57+00:00

Make __blk_crypto_bio_prep() propagate BLK_STS_INVAL when IO segments fail the data unit alignment check. This was flagged by an LTP test that expects EINVAL when performing an O_DIRECT read with a misaligned buffer [1]. Cc: Eric Biggers Cc: Christoph Hellwig Link: https://lore.kernel.org/all/aP-c5gPjrpsn0vJA@google.com/ [1] Signed-off-by: Carlos Llamas Reviewed-by: Eric Biggers Signed-off-by: Jens Axboe

blk-crypto: add ioctls to create and prepare hardware-wrapped keys

2025-02-10T16:54:19+00:00

Until this point, the kernel can use hardware-wrapped keys to do encryption if userspace provides one -- specifically a key in ephemerally-wrapped form. However, no generic way has been provided for userspace to get such a key in the first place. Getting such a key is a two-step process. First, the key needs to be imported from a raw key or generated by the hardware, producing a key in long-term wrapped form. This happens once in the whole lifetime of the key. Second, the long-term wrapped key needs to be converted into ephemerally-wrapped form. This happens each time the key is "unlocked". In Android, these operations are supported in a generic way through KeyMint, a userspace abstraction layer. However, that method is Android-specific and can't be used on other Linux systems, may rely on proprietary libraries, and also misleads people into supporting KeyMint features like rollback resistance that make sense for other KeyMint keys but don't make sense for hardware-wrapped inline encryption keys. Therefore, this patch provides a generic kernel interface for these operations by introducing new block device ioctls: - BLKCRYPTOIMPORTKEY: convert a raw key to long-term wrapped form. - BLKCRYPTOGENERATEKEY: have the hardware generate a new key, then return it in long-term wrapped form. - BLKCRYPTOPREPAREKEY: convert a key from long-term wrapped form to ephemerally-wrapped form. These ioctls are implemented using new operations in blk_crypto_ll_ops. Signed-off-by: Eric Biggers Tested-by: Bartosz Golaszewski # sm8650 Link: https://lore.kernel.org/r/20250204060041.409950-4-ebiggers@kernel.org Signed-off-by: Jens Axboe

blk-crypto: add basic hardware-wrapped key support

2025-02-10T16:54:19+00:00

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 raw keys in kernel memory, without limiting the number of keys that can be used. Such hardware also supports deriving a "software secret" for cryptographic tasks that can't be handled by inline encryption; this is needed for fscrypt to work properly. To support this hardware, allow struct blk_crypto_key to represent a hardware-wrapped key as an alternative to a raw 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. Signed-off-by: Eric Biggers Tested-by: Bartosz Golaszewski # sm8650 Link: https://lore.kernel.org/r/20250204060041.409950-2-ebiggers@kernel.org Signed-off-by: Jens Axboe

blk-crypto: make blk_crypto_evict_key() more robust

2023-03-16T15:35:09+00:00

If blk_crypto_evict_key() sees that the key is still in-use (due to a bug) or that ->keyslot_evict failed, it currently just returns while leaving the key linked into the keyslot management structures. However, blk_crypto_evict_key() is only called in contexts such as inode eviction where failure is not an option. So actually the caller proceeds with freeing the blk_crypto_key regardless of the return value of blk_crypto_evict_key(). These two assumptions don't match, and the result is that there can be a use-after-free in blk_crypto_reprogram_all_keys() after one of these errors occurs. (Note, these errors *shouldn't* happen; we're just talking about what happens if they do anyway.) Fix this by making blk_crypto_evict_key() unlink the key from the keyslot management structures even on failure. Also improve some comments. Fixes: 1b2628397058 ("block: Keyslot Manager for Inline Encryption") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20230315183907.53675-2-ebiggers@kernel.org Signed-off-by: Jens Axboe