linux-kernel - Re: [PATCH] mmc: block: ioctl: Poll for TRAN if possible

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]

Date:   Wed, 23 Jun 2021 13:45:10 +0000
From:   Christian Löhle <CLoehle@...erstone.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>
CC:     Avri Altman <Avri.Altman@....com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "shawn.lin@...k-chips.com" <shawn.lin@...k-chips.com>
Subject: Re: [PATCH] mmc: block: ioctl: Poll for TRAN if possible

Sorry Uffe, Im not quite ready and need some more testing myself before v2.
But I can outline and reason the need for a (now bigger) patch already.

mmc_ready_for_data checks for R1_STATE_TRAN also, comment says something
about cards abusing status bits, please warn me if this is an actual issue and in
what direction (From the code I'm assuming R1_READY_FOR_DATA may be
set when the card is not actually ready, but R1_READY_FOR_DATA is not unset
'randomly')

But for v2 I would keep the ready_for_data check on R1b commands,
but actually only check for R1_READY_FOR_DATA without any state.
(This could include Shawn's hardware busy_detect patch).
Then afterwards, for return_to_tran commands, do additional CMD13 polling.

I'm still struggling to get this 'clean' and race-condition free, because of e.g.
CMD5 MMC_SLEEP_AWAKE always signals busy, but only transitions to TRAN if
sleep bit is not set. Busy detection should be done in both cases, though.
(I then should be able to send MMC_SLEEP_AWAKE sleep and
MMC_SLEEP_AWAKE awake and MMC_SLEEP_AWAKE sleep in direct
succession from user space through the ioctl interface without any further
considerations from there.)
But clearly MMC_SLEEP_AWAKE sleep will never respond to a CMD13 with
busy bit unset, as it is in sleep then. (Shawns's hardware patch could be used
as a best effort.)
Maybe I'm overthinking this for an edge case of a rarely used ioctl interface,
but that is my status so far.
If I leave out perfect MMC_SLEEP_AWAKE behavior (and maybe something else)
then:
if (rpmb or R1b response)
    card_busy_detect (status bit only)
if (return_to_tran_cmd)
    card_poll_until_tran (using cmd13)

would be ideal.
Feel free to comment on my thoughts so far, until I've tested it some more.

Best Regards,
Christian

From: Ulf Hansson <ulf.hansson@...aro.org>
>I need some more time to review, but feel free to post a v2, I can
>look at that instead.
>
>Kind regards
>Uffe

Hyperstone GmbH | Line-Eid-Strasse 3 | 78467 Konstanz
Managing Directors: Dr. Jan Peter Berns.
Commercial register of local courts: Freiburg HRB381782