public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Ball <cjb@laptop.org>
To: Andrei Warkentin <awarkentin@vmware.com>
Cc: Ulf Hansson <ulf.hansson@stericsson.com>,
	Per Forlin <per.forlin@stericsson.com>,
	Lee Jones <lee.jones@linaro.org>,
	Johan Rudholm <johan.rudholm@stericsson.com>,
	John Beckett <john.beckett@stericsson.com>,
	linux-mmc@vger.kernel.org
Subject: Re: [PATCH] mmc: boot partition ro lock support
Date: Sat, 22 Oct 2011 06:32:32 -0400	[thread overview]
Message-ID: <m24nz171vj.fsf@bob.laptop.org> (raw)
In-Reply-To: <1817564019.180377.1319247876337.JavaMail.root@zimbra-prod-mbox-2.vmware.com> (Andrei Warkentin's message of "Fri, 21 Oct 2011 18:44:36 -0700 (PDT)")

Hi,

(Andrei, looks like your mails are being hard line wrapped around 100 cols.)

On Fri, Oct 21 2011, Andrei Warkentin wrote:
> What does power locking do that force_ro currently doesn't achieve?

The power-lock is used to go read only until the next time power is
reset, even if the kernel later asks for r/w.  This is used on some
devices such as the HTC Desire Z/G2 as a security mechanism -- the
bootloader switches to power r/o just before running the kernel, so
the kernel itself can't modify the boot kernel image.

.. except it can, because the G2 hackers worked out how to glitch the
eMMC's power rail using a kernel module that hits a GPIO, making it come
out of r/o, and managed to make the MMC layer cope with the device
needing reinit without crashing userspace.  But you get the idea.

> The permalocking brick-potential (more like paper-weight-potential) is
> IMO unacceptably high that something like this is just accessible via
> a sysfs attribute. This is exactly why the boot partitions were put
> under force_ro, so that some poor sap wouldn't end up nuking the boot
> partitions (with obvious consequences), and permalocking seems even
> nastier.

I agree.  Does anyone have an argument for including either of these?

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

  reply	other threads:[~2011-10-22 10:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-21 13:17 [PATCH] mmc: boot partition ro lock support Ulf Hansson
2011-10-22  1:44 ` Andrei Warkentin
2011-10-22 10:32   ` Chris Ball [this message]
2011-10-22 16:33     ` Linus Walleij
2011-10-22 16:55       ` Chris Ball
2011-10-23  0:51         ` Sebastian Rasmussen
2011-10-23  6:38           ` Chris Ball
2011-10-24  9:23             ` Ulf Hansson
2011-10-24 10:08               ` Chris Ball
2011-10-24 12:22                 ` Johan RUDHOLM
2011-10-25 21:31                   ` Andrei E. Warkentin
2011-11-22 12:15                 ` Johan RUDHOLM
2011-10-24 18:20             ` J Freyensee

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=m24nz171vj.fsf@bob.laptop.org \
    --to=cjb@laptop.org \
    --cc=awarkentin@vmware.com \
    --cc=johan.rudholm@stericsson.com \
    --cc=john.beckett@stericsson.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=per.forlin@stericsson.com \
    --cc=ulf.hansson@stericsson.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox