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

[Wolfgang Denk]

Dear Graeme,

In message <4F38F91D.6070301 at gmail.com> you wrote:
> 
> > 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).
> 
> Ah, so there will still be a 'gate' beyond which access must be validated.
> You are suggesting a hardware check of a GPIO pin or, if the hardware does
> not provide for that, maybe a serial or USB dongle...

USB dongle is definitely on the far end, but why not - if you have
such a sort of S & M preferences ;-)

Normally a jumper or DIP switch would be used - which is trivial to
implement.

> GPIO case is the same, you need to read the GPIO pin and if not set, skip
> entering command line

Which is trivial.  Just implement the test in misc_init_r(), and use
this to set bootdelay to 0 or -1 or similar.

> Again, my suggestion was, prior to entering command line, require a
> password to be entered - If the hash of the password matches a given
> environment variable, do exactly what the GPIO or dongle read returned true
> - enter unrestricted command line

I understand your proposal, and actually we already have that!  See
the documentation in doc/README.autoboot 

But you were talking about security - guess how many of such systems
will all run with the very same password?  And guess how long it will
take until it is publicly known?

Even if you extend this feature to store only a hash of the password,
and compare the hashes, the fundamental problem will remain:  How can
you precent that the passwords get faster pblicly known than you can
change them?

What do you do in case the user forgets the password?  Will he have to
return his box for repair or even replacement?

Of will there be some additional "master password" which is only
known to your field circus engineers (and after a few days to all
hackers in the whole world)?


> > password = key.  How are going to manage these?
> 
> I've said before, a hash of the password as an environment variable

This does not answer how you intend to handle the obvious problems -
see above.


> Well that (level based access to individual commands) was only a wild
> speculation on the future. My initial thought was just a simple gate prior
> to U-Boot getting to command line - Basically just a password hash
> validation in place of the existing 'abort auto-boot string' compare which
> is easily circumvented by obtaining the source code

You trade one problem for another.  Guess how many users will call
service because they have forgotten their password settings?

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
"The glory of creation is in its infinite diversity." "And in the way
our differences combine to create meaning and beauty."
	-- Dr. Miranda Jones and Spock, "Is There in Truth No Beauty?",
	   stardate 5630.8