public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Christian Löhle" <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
Date: Wed, 5 Apr 2023 11:57:15 +0000	[thread overview]
Message-ID: <20620b972fe448f381c3d585a1ae4730@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: 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


                 reply	other threads:[~2023-04-05 11:57 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=20620b972fe448f381c3d585a1ae4730@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