linux-kernel - RE: [PATCH] mmc: block: Dont report successful writes with errors

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]

Date:   Fri, 29 Jul 2022 14:20:58 +0000
From:   Christian Loehle <CLoehle@...erstone.com>
To:     Adrian Hunter <adrian.hunter@...el.com>,
        "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
        Avri Altman <Avri.Altman@....com>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        Linux MMC List <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] mmc: block: Dont report successful writes with errors

>> If not I would at least add the !mmc_is_host_spi condition for calling mmc_blk_status_error to make it a bit more clear that this function does do what is intended for SPI cards.
>
>I am not sure what you mean.  Isn't it OK to check CMD13 response for SPI?

You can do that for sure, but e.g. without some knowledge about what state you're in it doesn't tell you a lot.
If you get all zeroes after a write e.g., you cannot always tell if the SPI card is holding the line LOW because of busy[*], or you actually got an SPI R2 with no error bits set. (The CMD12 = ILLEGAL assert would fix it, but now all cards behave this way and the spec doesn't mandate it.)
It cannot really be dealt with in a nice manner.
Furthermore cards are, according to spec, free to treat cmd13 as ILLEGAL during data state.
If so, that's nice for us, we get a 0x4 back and know we have to fix state, some cards also
accept CMD13 (no error bits set), perfectly legal, but we don't know if we should fix state or not.
(Furthermore, how to fix state is then dependent on the issued (e.g. timedout command)

*The SD SPI spec e.g. says in 7.2.8 that a CMD13 must ALWAYS be responded to, but that is clearly not the intention of the spec, a card always listening for CMD13 in RCV state simply doesn't make sense.

Hyperstone GmbH | Reichenaustr. 39a  | 78467 Konstanz
Managing Director: Dr. Jan Peter Berns.
Commercial register of local courts: Freiburg HRB381782