linux-kernel - Re: [PATCH v3] mmc: Avoid reprogram all keys to Inline Crypto Engine for MMC runtime suspend resume

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <9a07d235-d1be-447b-ae89-75aa418cb69c@oss.qualcomm.com>
Date: Thu, 8 Jan 2026 10:43:39 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Neeraj Soni <neeraj.soni@....qualcomm.com>,
        Debraj Mukhopadhyay <quic_dmukhopa@...cinc.com>,
        Eric Biggers <ebiggers@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Adrian Hunter <adrian.hunter@...el.com>
Cc: linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, kernel@...cinc.com,
        Neeraj Soni <quic_neersoni@...cinc.com>,
        Ram Prakash Gupta <quic_rampraka@...cinc.com>,
        Nitin Rawat <quic_nitirawa@...cinc.com>,
        Sachin Gupta <quic_sachgupt@...cinc.com>,
        Bhaskar Valaboju <quic_bhaskarv@...cinc.com>,
        Gaurav Kashyap <quic_gaurkash@...cinc.com>,
        Sarthak Garg <quic_sartgarg@...cinc.com>
Subject: Re: [PATCH v3] mmc: Avoid reprogram all keys to Inline Crypto Engine
 for MMC runtime suspend resume

On 1/6/26 7:49 AM, Neeraj Soni wrote:
> Hi,
> 
> Aplogies for replying so late to the queries.
> 
> On 7/18/2025 5:35 PM, Konrad Dybcio wrote:
>> On 7/18/25 1:02 PM, Debraj Mukhopadhyay wrote:
>>> Crypto reprogram all keys is called for each MMC runtime
>>> suspend/resume in current upstream design. If this is implemented
>>> as a non-interruptible call to TEE for security, the cpu core is
>>> blocked for execution while this call executes although the crypto
>>> engine already has the keys. For example, glitches in audio/video
>>> streaming applications have been observed due to this. Add the flag
>>> MMC_CAP2_CRYPTO_NO_REPROG as part of host->caps2 to control reprogramming
>>> keys to crypto engine for socs which dont require this feature.
>>>
>>> Signed-off-by: Seshu Madhavi Puppala <quic_spuppala@...cinc.com>
>>> Co-developed-by: Ram Prakash Gupta <quic_rampraka@...cinc.com>
>>> Signed-off-by: Ram Prakash Gupta <quic_rampraka@...cinc.com>
>>> Co-developed-by: Sarthak Garg <quic_sartgarg@...cinc.com>
>>> Signed-off-by: Sarthak Garg <quic_sartgarg@...cinc.com>
>>> Signed-off-by: Debraj Mukhopadhyay <quic_dmukhopa@...cinc.com>
>>>
>>> ---

[...]

>>> @@ -459,6 +459,11 @@ struct mmc_host {
>>>  #define MMC_CAP2_CRYPTO		0
>>>  #endif
>>>  #define MMC_CAP2_ALT_GPT_TEGRA	(1 << 28)	/* Host with eMMC that has GPT entry at a non-standard location */
>>> +#ifdef CONFIG_MMC_CRYPTO
>>> +#define MMC_CAP2_CRYPTO_NO_REPROG	(1 << 29)	/* Host handles inline crypto key reprogramming */
>>> +#else
>>> +#define MMC_CAP2_CRYPTO_NO_REPROG	0
>>> +#endif
>> This (and the crypto ifdef for MMC_CAP2_CRYPTO) looks like unnecessary
>> churn - crypto functions should never be called if the config is disabled
>> in the first place
> Do you suggest to remove #ifdef? I am not sure why #ifdef is used with MMC_CAP2_CRYPTO
> (may be to reuse the bits if config is not defined) but for MMC_CAP2_CRYPTO_NO_REPROG we
> followed the approach used for MMC_CAP2_CRYPTO.

We got plenty of bits, let's not waste the time of a programmer trying
to figure out whether his particular combination of configs is going to
collide with the reuse, I'd argue the ifdef is unnecessary

Konrad