From: Brian Norris <computersforpeace@gmail.com>
To: <linux-mtd@lists.infradead.org>
Cc: "Brian Norris" <computersforpeace@gmail.com>,
"Rafał Miłecki" <zajec5@gmail.com>,
"Ezequiel Garcia" <ezequiel@vanguardiasur.com.ar>,
"Boris Brezillon" <boris.brezillon@free-electrons.com>,
linux-kernel@vger.kernel.org,
"Bayi Cheng" <bayi.cheng@mediatek.com>,
"Marek Vasut" <marex@denx.de>,
djkurtz@chromium.org
Subject: [PATCH v2 4/8] mtd: spi-nor: disallow further writes to SR if WP# is low
Date: Fri, 29 Jan 2016 11:25:33 -0800 [thread overview]
Message-ID: <1454095537-130536-5-git-send-email-computersforpeace@gmail.com> (raw)
In-Reply-To: <1454095537-130536-1-git-send-email-computersforpeace@gmail.com>
Locking the flash is most useful if it provides real hardware security.
Otherwise, it's little more than a software permission bit.
A reasonable use case that provides real HW security might be like
follows:
(1) hardware WP# is deasserted
(2) program flash
(3) flash range is protected via status register
(4) hardware WP# is asserted
(5) flash protection range can no longer be changed, until WP# is
deasserted
In this way, flash protection is co-owned by hardware and software.
Now, one would expect to be able to perform step (3) with
ioctl(MEMLOCK), except that the spi-nor driver does not set the Status
Register Protect bit (a.k.a. Status Register Write Disable (SRWD)), so
even though the range is now locked, it does not satisfy step (5) -- it
can still be changed by a call to ioctl(MEMUNLOCK).
So, let's enable status register protection after the first lock
command, and disable protection only when the flash is fully unlocked.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
---
v2:
* added clearing the SRWD bit when unlocking the entire flash
drivers/mtd/spi-nor/spi-nor.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 68133b949fe5..54eaf4b5bf05 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -540,6 +540,9 @@ static int stm_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
status_new = (status_old & ~mask) | val;
+ /* Disallow further writes if WP pin is asserted */
+ status_new |= SR_SRWD;
+
/* Don't bother if they're the same */
if (status_new == status_old)
return 0;
@@ -605,6 +608,10 @@ static int stm_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
status_new = (status_old & ~mask) | val;
+ /* Don't protect status register if we're fully unlocked */
+ if (lock_len == mtd->size)
+ status_new &= ~SR_SRWD;
+
/* Don't bother if they're the same */
if (status_new == status_old)
return 0;
--
2.7.0.rc3.207.g0ac5344
next prev parent reply other threads:[~2016-01-29 19:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-29 19:25 [PATCH v2 0/8] mtd: spi-nor: locking fixes and updates Brian Norris
2016-01-29 19:25 ` [PATCH v2 1/8] mtd: spi-nor: wait for SR_WIP to clear on initial unlock Brian Norris
2016-01-29 19:25 ` [PATCH v2 2/8] mtd: spi-nor: silently drop lock/unlock for already locked/unlocked region Brian Norris
2016-01-29 19:25 ` [PATCH v2 3/8] mtd: spi-nor: make lock/unlock bounds checks more obvious and robust Brian Norris
2016-01-29 19:25 ` Brian Norris [this message]
2016-01-29 19:25 ` [PATCH v2 5/8] mtd: spi-nor: use BIT() for flash_info flags Brian Norris
2016-01-29 19:25 ` [PATCH v2 6/8] mtd: spi-nor: add SPI_NOR_HAS_LOCK flag Brian Norris
2016-02-28 19:23 ` Ezequiel Garcia
2016-01-29 19:25 ` [PATCH v2 7/8] mtd: spi-nor: add TB (Top/Bottom) protect support Brian Norris
2016-02-29 20:35 ` Ezequiel Garcia
2016-03-08 2:12 ` Brian Norris
2016-01-29 19:25 ` [PATCH v2 8/8] mtd: spi-nor: support lock/unlock for a few Winbond chips Brian Norris
2016-02-27 2:04 ` [PATCH v2 0/8] mtd: spi-nor: locking fixes and updates Ezequiel Garcia
2016-03-08 2:18 ` Brian Norris
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=1454095537-130536-5-git-send-email-computersforpeace@gmail.com \
--to=computersforpeace@gmail.com \
--cc=bayi.cheng@mediatek.com \
--cc=boris.brezillon@free-electrons.com \
--cc=djkurtz@chromium.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=zajec5@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.