Re: [PATCH v1 10/11] blk-crypto: add slot_offset to blk_crypto_profile

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Loops iterating over keyslots in block and driver crypto initialization and reprogramming paths pass logical indices instead of physical indices to keyslot_program/keyslot_evict, failing to account for the new slot_offset.
--

commit 2859a14efba8a99150c0d93c45a6b7ad003d0250
Author: linlzhan <linlin.zhang@oss.qualcomm.com>

blk-crypto: add slot_offset to blk_crypto_profile
    
On platforms where ICE keyslots are partitioned across the host and
guest VMs, the host's physical keyslot range does not necessarily start
at slot 0.  blk_crypto_keyslot_index() currently returns a 0-based
array index, which is wrong for such configurations — hardware
programming requires the physical slot number, not the array position.

Add an unsigned int slot_offset field to struct blk_crypto_profile.
It defaults to zero (no change for existing drivers) and is set by
storage drivers that share ICE hardware across guests.

Update blk_crypto_keyslot_index() to add slot_offset to the array
index so that callers always receive the correct physical ICE keyslot
number to program into hardware.

> diff --git a/block/blk-crypto-profile.c b/block/blk-crypto-profile.c
> index 53126c091b0be..64202d64a0182 100644
> --- a/block/blk-crypto-profile.c
> +++ b/block/blk-crypto-profile.c
> @@ -218,14 +218,15 @@ blk_crypto_find_and_grab_keyslot(struct blk_crypto_profile *profile,
>  }
>  
>  /**
> - * blk_crypto_keyslot_index() - Get the index of a keyslot
> + * blk_crypto_keyslot_index() - Get the physical index of a keyslot
>   * @slot: a keyslot that blk_crypto_get_keyslot() returned
>   *
> - * Return: the 0-based index of the keyslot within the device's keyslots.
> + * Return: the physical ICE keyslot index, i.e. the 0-based position of @slot
> + * within the profile's keyslot array plus @slot->profile->slot_offset.
>   */
>  unsigned int blk_crypto_keyslot_index(struct blk_crypto_keyslot *slot)
>  {
> -	return slot - slot->profile->slots;
> +	return (slot - slot->profile->slots) + slot->profile->slot_offset;
>  }
>  EXPORT_SYMBOL_GPL(blk_crypto_keyslot_index);
>  

[ ... ]

> diff --git a/include/linux/blk-crypto-profile.h b/include/linux/blk-crypto-profile.h
> index 4f39e9cd75766..a9bdc05abfa3c 100644
> --- a/include/linux/blk-crypto-profile.h
> +++ b/include/linux/blk-crypto-profile.h
> @@ -162,6 +162,15 @@ struct blk_crypto_profile {
>  	 */
>  	struct device *dev;
>  
> +	/**
> +	 * @slot_offset: offset added to the slot array index to obtain the
> +	 * physical ICE keyslot number.  Zero in the common case.  Set to a
> +	 * non-zero value by storage drivers that share ICE hardware across
> +	 * multiple guests, where the host's keyslots do not start at physical
> +	 * slot 0.
> +	 */
> +	unsigned int slot_offset;
> +

[Severity: Critical]
Does this new slot_offset need to be applied in loops that manually iterate
over keyslots?

For example, in block/blk-crypto-profile.c:blk_crypto_reprogram_all_keys(),
the logical loop counter slot is passed directly to keyslot_program():

	for (slot = 0; slot < profile->num_slots; slot++) {
		...
		err = profile->ll_ops.keyslot_program(profile, key, slot);
		...
	}

Since this bypasses the new slot_offset, will it program keys into physical
slots starting at 0 during device resume, corrupting foreign keyslots belonging
to the host or other VMs?

Similarly, in drivers/ufs/core/ufshcd-crypto.c:ufshcd_init_crypto():

	for (slot = 0; slot < hba->crypto_profile.num_slots; slot++)
		hba->crypto_profile.ll_ops.keyslot_evict(&hba->crypto_profile,
							 NULL, slot);

And in drivers/mmc/host/cqhci-crypto.c:cqhci_crypto_init():

	for (slot = 0; slot < profile->num_slots; slot++)
		profile->ll_ops.keyslot_evict(profile, NULL, slot);

Do these initialization paths also incorrectly evict physical keyslots starting
at 0 because they ignore slot_offset, destroying host/guest ICE keyslots?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827160806.1295313-1-linlin.zhang@oss.qualcomm.com?part=10