linux-kernel - Re: [PATCH] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZZfCrLr5isWF/bwN@trux>
Date: Fri, 5 Jan 2024 09:49:48 +0100
From: "Jorge Ramirez-Ortiz, Foundries" <jorge@...ndries.io>
To: Adrian Hunter <adrian.hunter@...el.com>
Cc: "Jorge Ramirez-Ortiz, Foundries" <jorge@...ndries.io>,
	Avri Altman <Avri.Altman@....com>,
	"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
	michal.simek@....com, neal.frager@....com,
	sai.krishna.potthuri@....com,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mmc: rpmb: do not force a retune before RPMB switch

On 04/01/24 20:34:09, Adrian Hunter wrote:
> On 3/01/24 11:20, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 03/01/24 10:03:38, Adrian Hunter wrote:
> >> Thanks for doing that!  That seems to explain the mystery.
> >>
> >> You could hack the test to get an idea of how many successful
> >> iterations there are before getting an error.
> >>
> >> For SDHCI, one difference between tuning and re-tuning is the
> >> setting of bit-7 "Sampling Clock Select" of "Host Control 2 Register".
> >> It is initially 0 and then set to 1 after the successful tuning.
> >> Essentially, leaving it set to 1 is meant to speed up the re-tuning.
> >> You could try setting it to zero instead, and see if that helps.
> >> e.g.
> >>
> >> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> >> index c79f73459915..714d8cc39709 100644
> >> --- a/drivers/mmc/host/sdhci.c
> >> +++ b/drivers/mmc/host/sdhci.c
> >> @@ -2732,6 +2732,7 @@ void sdhci_start_tuning(struct sdhci_host *host)
> >>  	ctrl |= SDHCI_CTRL_EXEC_TUNING;
> >>  	if (host->quirks2 & SDHCI_QUIRK2_TUNING_WORK_AROUND)
> >>  		ctrl |= SDHCI_CTRL_TUNED_CLK;
> >> +	ctrl &= ~SDHCI_CTRL_TUNED_CLK;
> >>  	sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
> >>
> >>  	/*
> >>
> >
> >
> > Yes with that change, the re-tuning reliability test does pass.
> >
> > root@...cg-dwg-sec:/sys/kernel/debug/mmc0#  echo 52 > /sys/kernel/debug/mmc0/mmc0\:0001/test
> > [  237.833585] mmc0: Starting tests of card mmc0:0001...
> > [  237.838759] mmc0: Test case 52. Re-tuning reliability...
> > [  267.845403] mmc0: Result: OK
> > [  267.848365] mmc0: Tests completed.
> >
> >
> > Unfortunately I still see the error when looping on RPMB reads.
> >
> > For instance with this test script
> >  $ while true; do rpmb_read m4hash; usleep 300; done
> >
> > I can see the error triggering on the serial port after a minute or so.
> > [  151.682907] sdhci-arasan ff160000.mmc: __mmc_blk_ioctl_cmd: data error -84
> >
> > Causing OP-TEE to panic since the RPMB read returns an error
> > E/TC:? 0
> > E/TC:? 0 TA panicked with code 0xffff0000
> > E/LD:  Status of TA 22250a54-0bf1-48fe-8002-7b20f1c9c9b1
> > E/LD:   arch: aarch64
> > [...]
> >
> > if anything else springs to your mind I am happy to test of course - there are
> > so many tunnables in this subsystem that experience is this area has exponential
> > value (and I dont have much).
> >
> > Would it make sense if re-tuning requests are rejected unless a minimum number
> > of jiffies have passed? should I try that as a change?
> >
> > or maybe delay a bit longer the RPMB access after a retune request?
>
> It seems re-tuning is not working properly, so ideally the
> SoC vendor / driver implementer would provide a solution.


Makes sense to me too. I am copying Michal on the DL.


>
> There is also mmc_doing_retune() which could be used to skip
> tuning execution entirely in the case of re-tuning.
>