[dm-devel] [PATCH v4 3/4] blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
Mike Snitzer
snitzer at redhat.com
Wed Oct 6 13:28:20 UTC 2021
On Wed, Sep 29 2021 at 12:35P -0400,
Eric Biggers <ebiggers at kernel.org> wrote:
> From: Eric Biggers <ebiggers at google.com>
>
> 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 at linaro.org> # For MMC
> Signed-off-by: Eric Biggers <ebiggers at google.com>
Unfortunate how fiddley this change forced you to get but it looks
like you've done a very solid job of cleaning it all up to be
consistent.
Reviewed-by: Mike Snitzer <snitzer at redhat.com>
More information about the dm-devel
mailing list