Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Christian Loehle <CLoehle@hyperstone.com>
To:     Ulf Hansson <ulf.hansson@linaro.org>,
        "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Adrian Hunter <adrian.hunter@intel.com>
CC:     Avri Altman <avri.altman@wdc.com>
Subject: [PATCHv2 0/2] mmc: block: ioctl: Enhance userspace err-checking
Thread-Topic: [PATCHv2 0/2] mmc: block: ioctl: Enhance userspace err-checking
Thread-Index: AdmO7mibZ40MpwCrTAyP3SbyU0LCTQ==
Date:   Thu, 25 May 2023 09:55:47 +0000
Message-ID: <92013b1430374efd84828f467cd64017@hyperstone.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Precedence: bulk

This series enhances the ioctl path so that userspace callers are
able to reliably check all error bits for their operation.

The current implementation poses the problem of error bits which
the caller cannot check, this is potentially a security issue.

If the phrase security issue has woken you up, but you haven't been using:
mmc-utils sanitize
mmc-utils erase secure-trim{1|2}
mmc-utils secure-erase
mmc-utils rpmb write-block
you can go back to sleep, sorry to bother you.
If you have, you are probably still fine, if there was no active
attacker sabotaging your eMMC, the secure operation probably
succeeded.
There is just no way to confirm that it actually has.

Examples include e.g. a flash-fail of the eMMC.
Card behavior differs here, R1 bit 19 could be set,
many cards will just shut off on flash-fail, so if you want to play
with this patch I would suggest aiming for WP_ERASE_SKIP,
although that technically doesn't need the patch, as WP groups could
be queried before and after erase.

sudo ./mmc writeprotect user set temp 0x0 $(($(blockdev --getsz /dev/mmcblk2))) /dev/mmcblk2
sudo ./mmc erase secure-erase 0 $(($(blockdev --getsz /dev/mmcblk2)-1)) /dev/mmcblk2

will yield

Executing Secure Erase from 0x00000000 to 0x0773ffff
High Capacity Erase Unit Size=524288 bytes
High Capacity Erase Timeout=600 ms
High Capacity Write Protect Group Size=2097152 bytes
RSP0: 0x00008900 # added by author, this is what the patch will add to RSP0
 Secure Erase Succeed!

even though no erase is issued.

v2:
- removed extra flag and made it default behavior for write or R1B
- aggregate error flag in resp[0] instead of abusing resp[1]
- avoid open loop busy polling and reuse __mmc_poll_for_busy

Christian Loehle (2):
  mmc: block: ioctl: do write error check for spi
  mmc: block: ioctl: Add PROG-error aggregation

 drivers/mmc/core/block.c   | 23 ++++++++++++-----------
 drivers/mmc/core/mmc_ops.c | 25 ++++++++++++++++++++++++-
 drivers/mmc/core/mmc_ops.h |  3 +++
 3 files changed, 39 insertions(+), 12 deletions(-)

-- 
2.37.3


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