From: Chris Ball <cjb@laptop.org>
To: Sebastian Rasmussen <sebras@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Andrei Warkentin <awarkentin@vmware.com>,
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: Sun, 23 Oct 2011 02:38:53 -0400 [thread overview]
Message-ID: <m2r5245i0y.fsf@bob.laptop.org> (raw)
In-Reply-To: <CAAgDR1P0F1oue29jj-N3AU60JkEJ7qQtt1oLURSNzptjaQLa7A@mail.gmail.com> (Sebastian Rasmussen's message of "Sun, 23 Oct 2011 02:51:13 +0200")
Hi Sebastian,
On Sat, Oct 22 2011, Sebastian Rasmussen wrote:
> Hi!
>
>> What we're worried about is someone issuing the perm read-only command,
>> and not realizing that it really means that they can never ever write
>> any more changes to their eMMC -- it's a one-time fuse
>
> I can see why you are worried that people may brick their devices.
> How about only adding the read-only-until-power-cycled command?
I think that makes sense. I'd be curious to hear if anyone thinks we
shouldn't even add that command, perhaps on grounds that "the kernel
shouldn't be enthusiastic about locking itself out of future access to
a device" or similar. As you say, the ioctl interface would still work.
>> I'd rather leave it to specialized manufacturing equipment.
>
> Sure, but then again permanent read-only commands seem to be
> able to be sent by writing a userspace tool that issues a ioctl(fd, 0xb3, ...)
> using the generic command interface by John Calixto mentioned by
> Andrei. I assume that what reassures you in this case is
> that CAP_SYS_RAWIO is required and perhaps also obscurity?
Yes, that's right -- running a userspace program that you explicitly
downloaded from somewhere and compiled is more intentional than
wondering what a kernel argument or sysfs node does and trying it.
(Maybe I'm special, but I often use kernel arguments and sysfs nodes
without reading their code or finding the best documentation for them
first, when trying to get something to work.)
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
next prev parent reply other threads:[~2011-10-23 6:39 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
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 [this message]
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=m2r5245i0y.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=linus.walleij@linaro.org \
--cc=linux-mmc@vger.kernel.org \
--cc=per.forlin@stericsson.com \
--cc=sebras@gmail.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