public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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
Date: Thu, 25 May 2023 09:55:47 +0000	[thread overview]
Message-ID: <92013b1430374efd84828f467cd64017@hyperstone.com> (raw)

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


                 reply	other threads:[~2023-05-25  9:55 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=92013b1430374efd84828f467cd64017@hyperstone.com \
    --to=cloehle@hyperstone.com \
    --cc=adrian.hunter@intel.com \
    --cc=avri.altman@wdc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox