STRUCT BLK_CRYPTO_LL_OPS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct blk_crypto_ll_ops(9) β€” the kernel API manual, but make it make sense

okay so bestie, welcome to the kernel API manual entry for struct blk_crypto_ll_ops β€” literally the low-level hooky-things that let your storage driver boss around inline encryption hardware. grab a strawberry drink πŸ“ and let's get into it.


✨ NAME ✨

struct blk_crypto_ll_ops β€” the functions that control inline encryption hardware. like, the actual driver-side callbacks. no cap. πŸ”₯


πŸ¦‹ SYNOPSIS πŸ¦‹

struct blk_crypto_ll_ops {
    int (*keyslot_program)(struct blk_crypto_profile *profile, const
struct blk_crypto_key *key, unsigned int slot);
    int (*keyslot_evict)(struct blk_crypto_profile *profile, const
struct blk_crypto_key *key, unsigned int slot);
    int (*derive_sw_secret)(struct blk_crypto_profile *profile, const u8
*eph_key, size_t eph_key_size, u8 sw_secret[BLK_CRYPTO_SW_SECRET_SIZE]);
    int (*import_key)(struct blk_crypto_profile *profile, const u8
*raw_key, size_t raw_key_size, u8
lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
    int (*generate_key)(struct blk_crypto_profile *profile, u8
lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
    int (*prepare_key)(struct blk_crypto_profile *profile, const u8
*lt_key, size_t lt_key_size, u8
eph_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
 };

that's the whole struct, copied exactly, don't come for me 🫢


πŸŽ€ Members πŸŽ€

πŸ’œ keyslot_program

Program a key into the inline encryption hardware.

So this one programs the key into the slot you specify in the inline encryption hardware β€” and yes, it just overwrites whatever key that keyslot might already be holding. rude but necessary. the keyslot is guaranteed to not be in-use by any I/O, so you're safe, bestie.

This is required if the device has keyslots. otherwise β€” like, if the device is a layered device, or if it's real hardware that simply doesn't have the concept of keyslots β€” it is never called. at all. ghosted. πŸ‘»

Must return 0 on success, or -errno on failure. periodt.

πŸ¦‹ keyslot_evict

Evict a key from the inline encryption hardware.

If the device has keyslots, this function must evict the key from the specified slot. the slot will contain key, but honestly there should be no need for the key argument to be used, since slot should be sufficient. the keyslot is guaranteed to not be in-use by any I/O. πŸ’…

If the device doesn't have keyslots itself, this function must evict key from any underlying devices. in that case slot won't be valid, bestie, watch out.

If there are no keyslots and no underlying devices? this function isn't required. you can just vibe.

Must return 0 on success, or -errno on failure.

🌸 derive_sw_secret

Derive the software secret from a hardware-wrapped key in ephemerally-wrapped form.

This only needs to be implemented if BLK_CRYPTO_KEY_TYPE_HW_WRAPPED is supported. iykyk.

Must return 0 on success, -EBADMSG if the key is invalid, or another -errno code on other errors.

⭐ import_key

Create a hardware-wrapped key by importing a raw key.

This only needs to be implemented if BLK_CRYPTO_KEY_TYPE_HW_WRAPPED is supported.

On success, must write the new key in long-term wrapped form to lt_key and return its size in bytes. On failure, must return a -errno value. mmkay? 😌

πŸ‘‘ generate_key

Generate a hardware-wrapped key.

This only needs to be implemented if BLK_CRYPTO_KEY_TYPE_HW_WRAPPED is supported.

On success, must write the new key in long-term wrapped form to lt_key and return its size in bytes. On failure, must return a -errno value. main character behavior honestly.

🧚 prepare_key

Prepare a hardware-wrapped key to be used.

So you prepare a hardware-wrapped key to be used by converting it from long-term wrapped form to ephemerally-wrapped form. this only needs to be implemented if BLK_CRYPTO_KEY_TYPE_HW_WRAPPED is supported.

On success, must write the key in ephemerally-wrapped form to eph_key and return its size in bytes. On failure, must return -EBADMSG if the key is invalid, or another -errno on other error.


🌈 Description 🌈

Low-level operations for controlling inline encryption hardware β€” the whole interface, the vibe check, the moment. this interface must be implemented by storage drivers that support inline encryption. it's giving mandatory.

okay and here's the important part: all functions may sleep, they are serialized by profile->lock, and they are never called while profile->dev (if set) is runtime-suspended. literally never. don't even think about it. 😭


πŸ” SEE ALSO πŸ”

  • Kernel file ./include/linux/blk-crypto-profile.h struct blk_crypto_profile(9)

and that's the tea, bestie 🍡 β€” this little gem lives in ./include/linux, dated October 2026, and it's the struct blk_crypto_ll_ops(9) page. slay, study it, and go encrypt something inline. πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from