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: <e1f689d0-523b-5842-3a6e-10b431d617ce@oss.qualcomm.com>
Date: Tue, 6 Jan 2026 11:14:55 +0530
From: Neeraj Soni <neeraj.soni@....qualcomm.com>
To: Ulf Hansson <ulf.hansson@...aro.org>,
        Debraj Mukhopadhyay <quic_dmukhopa@...cinc.com>,
        Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Eric Biggers <ebiggers@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>, 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,

Apologies on replying so late to the queries.

On 7/18/2025 6:27 PM, Ulf Hansson wrote:
> On Fri, 18 Jul 2025 at 14:05, Konrad Dybcio
> <konrad.dybcio@....qualcomm.com> 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?
> 
> I agree!
> 
> I also think it's important to also understand what runtime PM cycle
> we are discussing here. It's a bit blurry for me currently, can we
> please clarify this.
> 
> A runtime PM cycle of the card, means that the eMMC card is
> power-cycled and re-initialized (assuming MMC_CAP_AGGRESSIVE_PM is
> set, which I guess is a downstream patch as the upstream sdhci-msm
> driver doesn't have this bit set, at least not yet). The mmc host is
> probably also runtime PM power-cycled when the card is, but it's
> orthogonal to the runtime PM cycle of the card - that's a really
> important point here, I think.
> 
> As I understand it, the crypto context is not tied to the card, but to
> the mmc host. What happens with the crypto context when the mmc host
> is runtime PM cycled? Is the context preserved? I assume so, or?
Yes the crypto context is tied to the host not to the card. In QC case when 
the host is runtime pm cycled the crypto contexts are preserved hence reprogramming
is not needed.
> 
>>
>> 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
> 
> Yes, maybe. Let's see> 
> [...]
> 
> Kind regards
> Uffe
> 
>