linux-kernel - Re: [PATCH v4] 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: <20260122011417.GB946159@google.com>
Date: Thu, 22 Jan 2026 01:14:17 +0000
From: Eric Biggers <ebiggers@...nel.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Neeraj Soni <neeraj.soni@....qualcomm.com>, adrian.hunter@...el.com,
	quic_dmukhopa@...cinc.com, quic_rampraka@...cinc.com,
	quic_nitirawa@...cinc.com, quic_sachgupt@...cinc.com,
	quic_bhaskarv@...cinc.com, quic_gaurkash@...cinc.com,
	quic_sartgarg@...cinc.com, linux-mmc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v4] mmc: Avoid reprogram all keys to Inline Crypto Engine
 for MMC runtime suspend resume

On Wed, Jan 21, 2026 at 03:12:43PM +0100, Ulf Hansson wrote:
> > diff --git a/drivers/mmc/core/crypto.c b/drivers/mmc/core/crypto.c
> > index fec4fbf16a5b..a5a90bfc634e 100644
> > --- a/drivers/mmc/core/crypto.c
> > +++ b/drivers/mmc/core/crypto.c
> > @@ -15,7 +15,7 @@
> >  void mmc_crypto_set_initial_state(struct mmc_host *host)
> >  {
> >         /* Reset might clear all keys, so reprogram all the keys. */
> > -       if (host->caps2 & MMC_CAP2_CRYPTO)
> > +       if ((host->caps2 & MMC_CAP2_CRYPTO) && !(host->caps2 & MMC_CAP2_CRYPTO_NO_REPROG))
> >                 blk_crypto_reprogram_all_keys(&host->crypto_profile);
> 
> As far as I understand, calling blk_crypto_reprogram_all_keys() would
> only be needed for those mmc hosts that lose their corresponding ICE
> context during runtime+system suspend, reset and possibly during
> ->probe().
> 
> In other words, calling mmc_crypto_set_initial_state() from
> mmc_set_initial_state() looks like it's a mistake, as it has really
> nothing to do with the card's initialization, unless I have understood
> this wrong!?
> 
> That said, I would rather make the mtk-sd and sdhci-msm drivers to
> handle this themselves, by explicitly calling
> blk_crypto_reprogram_all_keys() when needed - and drop
> mmc_crypto_set_initial_state() altogether.
> 
> For the sdhci-msm case, it seems like the only case we need to care
> about is for the reset.
> 
> For mtk-sd I don't know what is needed, but possibly Eric can help out here?

The comment for mmc_set_initial_state() says "Set initial state after a
power cycle or a hw_reset."  I relied on that when I added the call to
mmc_crypto_set_initial_state() back in 2020.  In the following thread it
was also discussed that the code was intended to reprogram the keys on
reset, not runtime suspend as that shouldn't be needed:
https://lore.kernel.org/linux-mmc/X7gQ9Y44iIgkiM64@sol.localdomain/T/#u

If that is not what it actually does, it probably would be appropriate
to replace it with something else.  

- Eric