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