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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <16c9c334-ab2a-4d24-9467-9a8faf572442@intel.com>
Date: Mon, 19 Jan 2026 14:31:04 +0200
From: Adrian Hunter <adrian.hunter@...el.com>
To: Neeraj Soni <neeraj.soni@....qualcomm.com>, <ulf.hansson@...aro.org>,
	<ebiggers@...nel.org>, <abel.vesa@...aro.org>
CC: <linux-mmc@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, Wenjia Zhang <wenjia.zhang@....qualcomm.com>
Subject: Re: [PATCH v4] mmc: host: sdhci-msm: Add support for wrapped keys

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@....qualcomm.com>
>>> Signed-off-by: Neeraj Soni <neeraj.soni@....qualcomm.com>
>>
>> Doesn't apply cleanly to mmc next.  Otherwise:
>>
>> Acked-by: Adrian Hunter <adrian.hunter@...el.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.