Re: [PATCH v4] mmc: host: sdhci-msm: Add support for wrapped keys

[Adrian Hunter <adrian.hunter@intel.com>]

On 19/01/2026 12:19, Neeraj Soni wrote:
> Hi,
> 
> On 1/12/2026 12:35 PM, Adrian Hunter wrote:
>> On 02/01/2026 14:40, Neeraj Soni wrote:
>>> Add the wrapped key support for sdhci-msm by implementing the needed
>>> methods in struct blk_crypto_ll_ops and setting the appropriate flag in
>>> blk_crypto_profile::key_types_supported.
>>>
>>> Tested on SC7280 eMMC variant.
>>>
>>> How to test:
>>>
>>> Use the "v1.3.0" tag from https://github.com/google/fscryptctl and build
>>> fscryptctl that supports generating wrapped keys.
>>>
>>> Enable the following config options:
>>> CONFIG_BLK_INLINE_ENCRYPTION=y
>>> CONFIG_QCOM_INLINE_CRYPTO_ENGINE=y
>>> CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
>>> CONFIG_MMC_CRYPTO=y
>>>
>>> Enable "qcom_ice.use_wrapped_keys" via kernel command line.
>>>
>>> $ mkfs.ext4 -F -O encrypt,stable_inodes /dev/disk/by-partlabel/vm-data
>>> $ mount /dev/disk/by-partlabel/vm-data -o inlinecrypt /mnt
>>> $ fscryptctl generate_hw_wrapped_key /dev/disk/by-partlabel/vm-data > /mnt/key.longterm
>>> $ fscryptctl prepare_hw_wrapped_key /dev/disk/by-partlabel/vm-data < /mnt/key.longterm > /tmp/key.ephemeral
>>> $ KEYID=$(fscryptctl add_key --hw-wrapped-key < /tmp/key.ephemeral /mnt)
>>> $ rm -rf /mnt/dir
>>> $ mkdir /mnt/dir
>>> $ fscryptctl set_policy --iv-ino-lblk-32 "$KEYID" /mnt/dir
>>> $ dmesg > /mnt/dir/test.txt
>>> $ sync
>>>
>>> Reboot the board
>>>
>>> $ mount /dev/disk/by-partlabel/vm-data -o inlinecrypt /mnt
>>> $ ls /mnt/dir # File should be encrypted
>>> $ fscryptctl prepare_hw_wrapped_key /dev/disk/by-partlabel/vm-data < /mnt/key.longterm > /tmp/key.ephemeral
>>> $ KEYID=$(fscryptctl add_key --hw-wrapped-key < /tmp/key.ephemeral /mnt)
>>> $ fscryptctl set_policy --iv-ino-lblk-32 "$KEYID" /mnt/dir
>>> $ cat /mnt/dir/test.txt # File should now be decrypted
>>>
>>> Tested-by: Wenjia Zhang <wenjia.zhang@oss.qualcomm.com>
>>> Signed-off-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
>>
>> Doesn't apply cleanly to mmc next.  Otherwise:
>>
>> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
>>
> Is this a blocker for the patch to get merged? I will anyway see why it is not applying cleanly on mmc next
> but wanted to know if this is necessary to resolve for these chagnes to get merged in Linux-next?
In this case, it is up to Ulf, but in general it is inadvisable
to assume a maintainer is willing to fix up patches that don't
apply cleanly.