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

[Wolfgang Denk]

Dear Graeme,

In message <4F378753.4070808 at gmail.com> you wrote:
> 
> > Do not do this in the boot loader.  It is not the environment for such
> > things.  When it comes to security, you are automatically pulling in
> > things like encryption technologies, key management, etc.  We do not
> > want to pull this into a bootloader - it would just be a poor mans
> > surrogate for a real OS.  Instead, do the logical step and use a
> > proper OS that provides all these things for free, in a well-tested
> > and protected environment.
> 
> The issue is that the bootloader has complete access and control of
> critical hardware components (Flash, environment storage, MAC address etc)
> and at the moment there is no effective protection.

There is nothing that a boot loadr can do, that cannot be done as well
by appropriate Linux kernel code.

> If all the bootloader did was transition to the OS without any support for
> an interactive environment then the would not be a problem (aside from
> hacking the hardware, but there is no way a bootloader can protect against
> that anyway, so the point is moot)

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/

> Suitable encryption is already in U-Boot (we have SHA and MD5 libraries
> already)

We have only checksumming. We do not have any kind of key management
whatever.

> > I disagree.  There are a large number of things that simply make no
> > sense in boot loader context.
> 
> I would agree if the bootloader did not have an interactive environment for
> providing low-level access to things that need to be protected. But U-Boot
> provides just that (and it is part of the reason so many people use it).

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.

> By having these function in the bootloader:
> a) The functionality is already there - they don't have to implement it
> (which may be practically prohibitive for some CoTS embedded OSs)
> a) They don't have to go all the way into the OS to use the functionality
> b) They don't have to put those functions in the OS and thus provide a
> potential security concern (if tools to modify the low-level environment
> are not in /sbin/ then gaining root access by a buffer overrun is not so
> serious)

Sorry, but I really cannot follow you.

> So you either do not implement any 'critical' functions in the bootloader
> (realistically that may mean not providing a command line at all) or secure
> the bootloader to the same level as the OS

Correct - in a protected environment I would not provide any
interactive functionality for U-Boot at all.  Everything else is _way_
too easy to break in.

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
Hello! I'm from outer space,  and I've made myself look like a signa-
ture.  While  you  are reading this, I'm having sex with your eyes. I
know it feels good to you, because you're smiling. I'm very horny, so
send me to someone else when you've had enough. Thanks!
                              Sincerely, A Stranger in a Strange Land