linux-kernel - Re: [PATCH] mmc: block: Differentiate busy and non-TRAN state

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:   Tue, 6 Jul 2021 09:09:16 +0000
From:   Christian Löhle <CLoehle@...erstone.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
CC:     "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Avri Altman <Avri.Altman@....com>,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH] mmc: block: Differentiate busy and non-TRAN state

Hey Uffe,

>> +static int is_return_to_tran_cmd(struct mmc_command *cmd)
>> +{
>> +       /*
>> +        * Cards will never return to TRAN after completing
>> +        * identification commands or MMC_SEND_STATUS if they are not selected.
>> +        */
>> +       switch (cmd->opcode) {
>> +       case MMC_GO_IDLE_STATE:
>> +       case MMC_SEND_OP_COND:
>> +       case MMC_ALL_SEND_CID:
>> +       case MMC_SET_RELATIVE_ADDR:
>> +       case MMC_SET_DSR:
>> +       case MMC_SLEEP_AWAKE:
>> +       case MMC_SELECT_CARD:
>> +       case MMC_SEND_CSD:
>> +       case MMC_SEND_CID:
>> +       case MMC_SEND_STATUS:
>> +       case MMC_GO_INACTIVE_STATE:
>> +       case MMC_APP_CMD:
>> +               return false;
>> +       default:
>> +               return true;
>> +       }
>> +}
>>
>What exactly are you trying to do with the user space program through
>the mmc ioctl with all these commands? The mmc ioctl interface is not
>designed to be used like that.
>
>In principle, it looks like we should support a complete
>re-initialization of the card. I am sorry, but no thanks! This doesn't
>work, but more importantly, this should be managed solely by the
>kernel, in my opinion.

Doing initialization itself through ioctl is silly, I agree, and does
not work on other ends. This patch is not about that. it just explicitly disables
any CMD13 polling for TRAN for some of those commands. the behavior
for such commands thus is the same as without the patch.
The reason for this patch is to not run into the race condition that a 
following (ioctl) command will be rejected because the card is in e.g. PROG state
of a previous ioctl command. As stated earlier, I encountered this a lot when
doing a unlock force erase -> lock/set, in both scenarios, issued as two single
ioctl commands and bundled together.
But this race condition exists on any (non-R1b/ RPBM) currently. As there is
no CMD13 polling happening after the response (or whenever the driver marks
the request as done), the card's status is therefore generally unknown.

So in short I don;t want to do anything too crazy from userspace, but the
alternative now is to do like 100ms sleeps in the hope that the card is
actually finished with the issued command (not just the host driver so to say).

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