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: <42797330-868a-bfcd-e0bb-b5f0dd3eeb16@oss.qualcomm.com>
Date: Tue, 6 Jan 2026 12:19:47 +0530
From: Neeraj Soni <neeraj.soni@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....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

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>
>>
>> ---
> 
> Let's take a step back - do we need to ever program this more than
> once on QC? What about other devices (e.g. the generic cqhci-crypto)?
> Do they also lose the crypto context over a runtime pm cycle?
> 
Yes crypto context is not lost during runtime pm as crypto context is tied to the host
where the context is preesrved in runtime pm cycle.
This needs to be programmed whenever host looses the crypto context like during power on
or device power reset.
 
> If our hardware is fine with set-it-and-forget-it approach, maybe
> we could limit this to a small if-condition sdhci-msm.c
QC hardware will be fine with this approach and we are doing so in this patch in
sdhci_msm_gcc_reset() API but it is not clear how other devices behave during runtime pm
hence a quirk is added in mmc_crypto_set_initial_state() to prevent reprogramming of
crypto context only for QC hardware.
> 
> [...]
> 
>> @@ -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.
> 
> Konrad
> 
Thanks
Neeraj