linux-kernel - Re: [PATCHv3] mmc: rpmb: do not force a retune before RPMB switch

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: <CAPDyKFpRD2euDm5cArZFcS3b9Zpr8yKL6vcyk4Sb77Vkr-YDZA@mail.gmail.com>
Date: Wed, 3 Jan 2024 13:21:18 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Jorge Ramirez-Ortiz <jorge@...ndries.io>
Cc: adrian.hunter@...el.com, Avri.Altman@....com, christian.loehle@....com, 
	ricardo@...ndries.io, linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org
Subject: Re: [PATCHv3] mmc: rpmb: do not force a retune before RPMB switch

On Wed, 3 Jan 2024 at 12:29, Jorge Ramirez-Ortiz <jorge@...ndries.io> wrote:
>
> Requesting a retune before switching to the RPMB partition has been
> observed to cause CRC errors on the RPMB reads (-EILSEQ).
>
> Since RPMB reads can not be retried, the clients would be directly
> affected by the errors.
>
> This commit disables the retune request prior to switching to the RPMB
> partition: mmc_retune_pause() no longer triggers a retune before the
> pause period begins.
>
> This was verified with the sdhci-of-arasan driver (ZynqMP) configured
> for HS200 using two separate eMMC cards (DG4064 and 064GB2). In both
> cases, the error was easy to reproduce triggering every few tenths of
> reads.
>
> With this commit, systems that were utilizing OP-TEE to access RPMB
> variables will experience an enhanced performance. Specifically, when
> OP-TEE is configured to employ RPMB as a secure storage solution, it not
> only writes the data but also the secure filesystem within the
> partition. As a result, retrieving any variable involves multiple RPMB
> reads, typically around five.
>
> For context, on ZynqMP, each retune request consumed approximately
> 8ms. Consequently, reading any RPMB variable used to take at the very
> minimum 40ms.
>
> After droping the need to retune before switching to the RPMB partition,
> this is no longer the case.
>
> Signed-off-by: Jorge Ramirez-Ortiz <jorge@...ndries.io>
> Acked-by: Avri Altman <avri.altman@....com>
> Acked-by: Adrian Hunter <adrian.hunter@...el.com>

Thanks for updating the commit message, very nice! And thanks Adrian
for reviewing this!

Applied for next, thanks!

Kind regards
Uffe

> ---
>  v3:
>     Added some performance information to the commit message
>  v2:
>     mmc_retune_pause() no longer can trigger a retune.
>     Keeping Avri Altman Acked-by since they are functionally equivalent.
>  v1:
>     modify mmc_retune_pause to optionally trigger a retune.
>
>
>  drivers/mmc/core/host.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 096093f7be00..ed44920e92df 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -119,13 +119,12 @@ void mmc_retune_enable(struct mmc_host *host)
>
>  /*
>   * Pause re-tuning for a small set of operations.  The pause begins after the
> - * next command and after first doing re-tuning.
> + * next command.
>   */
>  void mmc_retune_pause(struct mmc_host *host)
>  {
>         if (!host->retune_paused) {
>                 host->retune_paused = 1;
> -               mmc_retune_needed(host);
>                 mmc_retune_hold(host);
>         }
>  }
> --
> 2.34.1