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

Message-ID: <CAPDyKFqgo4ewJxPOUmY-GE+CG2XUVGQvEqgTQnvo0MfryMemGw@mail.gmail.com>
Date: Fri, 18 Jul 2025 14:57:21 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: 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

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?

>
> 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