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:   =?iso-8859-1?Q?Christian_L=F6hle?= <CLoehle@hyperstone.com>
To:     Ulf Hansson <ulf.hansson@linaro.org>,
        Adrian Hunter <adrian.hunter@intel.com>,
        "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
CC:     Avri Altman <avri.altman@wdc.com>
Subject: [RFC][PATCH 0/3] mmc: block: ioctl: Enhance userspace err-checking
Thread-Topic: [RFC][PATCH 0/3] mmc: block: ioctl: Enhance userspace
 err-checking
Thread-Index: AdlntVwS+89diB7ATPqDW+FoRq4nTA==
Date:   Wed, 5 Apr 2023 11:57:15 +0000
Message-ID: <20620b972fe448f381c3d585a1ae4730@hyperstone.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
Content-Type: text/plain;
        charset="iso-8859-1"
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: 0x00000800 # added by author, this is what the patch will add
RSP1: 0x00008f40 # added by author, this is what the patch will add
 Secure Erase Succeed!

even though no erase is issued.

Why is it RFC?
setting BIT(31) of write_flag is of course hacky, would like your
comments on that. The post-PROG errors are only relevant for
either writes or SWITCH and ERASE, so operations without data,
it can safely be abused.
Similarly saving the errors in response[1] is also a bit hacky,
I personally like it a bit better for the userspace caller to
be able to distinguish immediate errors and X errors.
Just putting everything in response[0] would of course work, too.

1/3 and 2/3 are fine from my end.

Christian Loehle (3):
  mmc: block: ioctl: define rpmb reliable flag
  mmc: block: ioctl: do write error check for spi
  mmc: block: ioctl: Add error aggregation flag

 drivers/mmc/core/block.c       | 48 ++++++++++++++++++++++++++++++----
 include/uapi/linux/mmc/ioctl.h |  3 +++
 2 files changed, 46 insertions(+), 5 deletions(-)

-- 
2.37.3


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