[U-Boot] Password protection of U-Boot command line

[Frans Meulenbroeks]

2012/2/10 Wolfgang Denk <wd at denx.de>:
> Dear Frans Meulenbroeks,
>
> In message <CACW_hTbGtYCLK380-FnGT01132e+yQ0Hhw-54LFXh4mV7XTr2g at mail.gmail.com> you wrote:
>> Generally speaking there is a use case for a password.
>
> Of course there is.  The question is if the oot loader is the right
> place for it.
>
>> E.g. if you deliver boards/systems with u-boot on it and you do not
>> want customers to enter u-boot (e.g. by accident or because they want
>> to hack the board), but you would allow authorized service personnel
>> to access the board.
>>
>> For this case a secret password in the image would probably suffice
>> (guess it might help to have it encrypted in flash or store a hash or
>> so.
>> Of course is the password leaks the security is gone.
>
> Right.  And we don't have anything like login names or users or
> priviledges in U-Boot, so all systems you ship would use the same
> master password. And the source code is under GPL and visible to
> everybody.  Guess how long your "security" lasts?

True; forgot about the GPL.
>
> If you want security, then don;t allow access to U-Boot at all, and
> run an OS.  There you can do fancy things, including password
> protection.

The issue is mainly that we would like a service engineer to upgrade
if for some reason the os goes into a not recoverable fault, without
an operator accidently (or on purpose) bumping into it
>
>> A password in env is more hackable. It would at least require no
>> access from the kernel to the section the env is in (so no userspace
>> tools and no /dev/mtd0 mapping to the whole flash).
>>
>> Yet another alternative (probably solution specific, is to store the
>> passwd in a separate eeprom or so and make sure it is not accessible
>> from the kernel (not always trivial)).
>
> Do you realize that you are already talking how to maintain this
> "security" level in Linux?  Then also implement it there!  That's
> where such stuff belongs to.
>
probably yes. my concern is mostly about being able to repair systems
where something is broken and the kernel does not come up as desired
but also does not crash and bring us back to u-boot (like what happens
if a crc is faulty).

What Mike suggests in a subsequent message of using is more or less
secret key is probably already enough for us.

Frans