[PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

Jared Hulbert jaredeh at gmail.com
Mon Nov 12 17:50:46 EST 2007


> Don't make the unlocking the default.  The flag has simply to be set
> explicitly for the unlock to occur.  Few reasons for this:
>
> 1) you don't know if a particular flash requires unlocking after boot,
>    (most flash models don't) so doing it unconditionally is wasteful;
>
> 2) the partition might as well be meant to remain locked, except for
>    rare occasions when its content is updated (think bootloader) meaning
>    it cannot be marked read-only;
>
> 3) this is a security feature and should not be bypassed "by
>    default", and therefore the auto-unlock should be dependent on an
>    explicit flag so people needing it will have the opportunity to think
>    about it.

Why is it a security feature to have a partition marked as r/w come up
as locked?  That's nutty.  If someone want's to implement some complex
scheme to prevent errant programs, they can use the userspace tools
and readonly flag for that.  The mailinglist gets an awful lot of
questions that have pointlessly locked partitions as the core.  Most
users don't use or view this as a security feature but just as an
annoyance.

So the semantics for the partition flags are to allow reads unless a
partition has been explictly marked readonly, right?   If you have
signaled intent to write to it, by creating a non-readonly partition,
you expect to be able to write to.  I argue it makes sense then to
unlock a partition that isn't marked readonly, granted we _only_
unlock such partitions.

I suggest we make this behavior (a) selective based on a config option
(b) make sure it only unlocks chips that actually unlock.



More information about the linux-mtd mailing list