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

[Wolfgang Denk]

Dear Graeme Russ,

In message <CALButCJyfBxrKURaG-ytk767D4Nfc5b6sN6O7Bdx+KH2GCC2Kg at mail.gmail.com> you wrote:
> 
> > There is nothing that a boot loadr can do, that cannot be done as well
> > by appropriate Linux kernel code.
> 
> Yes, but that access can be controlled through logon credentials after
> the OS has been loaded.

Well spotted.  And this is the very reason why I recommend doing these
things in Linux, and _not_ in the boot loader.

> > It is way easier to prevent a user from getting any interactive access
> > to the boot loader at all than it is to protect such access by a
> > password and open it only for "priviledged" users/
> 
> So basically you are suggesting to completely remove shell access in U-Boot
> which is one thing that make U-Boot so attractive.

Not remove it, but don't give the user an interactive shell when he is
running in production mode.  You can then still use it in scripts, or
when you switch to test mode (which should be doen through a jumper or
hardware dongle or similar, as discussed previously).

> > We have only checksumming. We do not have any kind of key management
> > whatever.
> 
> Why do we need key management - We aren't doing any decrypting (I'm not
> suggesting 'Secure Boot' here). All we are doing is comparing two
> passwords which we can use secure hashing functions like SHA or MD5 for

password = key.  How are going to manage these?

> > You don't have to open access to such "things that need to be
> > protected".  It is way easier not to provide such access at all then
> > to try and protect it with a password.
> 
> Again, you are suggesting removing functionality that attract people to
> U-Boot

You don't understand.

Adding security _always_ means removing certain "convenient" features.

Having a powerful, flexible tool that allows the user to do about
everything and defining a secure environment where a specific user
has only a well-defined set of capabilities are mutually exclusive by
definition.


> If you buy a CoTS OS for your embedded system, it may not come with a
> command line, let alone the tools already provided in U-Boot. So you then
> have the additional development cost of implementing all those features -

Use Linux, then.

> fine if your firmware is open source (you can just use the U-Boot code) but
> if those features need to be integrated into the CoTS source code, you have
> to go it alone (most PLC/RTU CoTS OSs are just a library that you link in
> your code to produce a single, monotomic binary so using GPL code is out
> of the question in those cases)

Ah!  So your problem is that you want to do inappropriate things
because your crappy, proprietary RTOS prevents you from doing the
rights things.

I'm sorry, but I don't commiserate with you about that.

> And if the OS you used does not have a command line, you have to implement
> that on top - Often a non-trivial endeavour

It would be a totally wrong conclusion, though, to try to turn the
boot loader in a wannabe OS just because it is more useful and capable
than your RTOS.

If your RTOS does not stand to your requirements, then fix the cause
of the problem, i. e. use a more capable OS.

> Better that the security be developed, analysed and maintained by a large
> group of open eyes than trusting your dev group of maybe two or three
> people get it right...

Agreed. Which is excatly why I prefer Free Software whenever it comes
to security, crypto-technology etc.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Little known fact about Middle Earth:   The Hobbits had a very sophi-
sticated computer network!   It was a Tolkien Ring...