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

[Wolfgang Denk]

Dear Graeme,

In message <4F35EBBF.3050106 at gmail.com> you wrote:
> 
> I do a lot of work with Programmable Logic Controllers (PLCs) and Remote
> Telemetry Units (RTUs). One example of what the bootloader is used for is
> low-level configuration of the analogue input out output channels
> (calibration). This is done by entering a command in the bootloader command
> line and applying a known calibrated input (if calibrating an input
> channel) or connecting to a calibrated measurement instrument (if
> calibrating an output). This is not something that an end-user should be
> doing (and can be very dangerous if the calibration is modified). These
> inputs and outputs may be connected to critical equipment, and if something
> goes wrong, the device manufacture needs a level of certainty that these
> settings have not been changed.
> 
> This is only one example - There are many other reasons that the end user
> should be 'kept out' of the bootloader.

This implies the logic that these actions _have_ to be done in the boot
loader, so you need to add security to it.

I doubt if this assumption is correct.  I think the calibration
couldbe done as well (and in a much beter secured environment) when
running an OS.

> There has also been a recent bout of security breaches as a result of
> hard-coded passwords in device firmware, so being able to set the password
> is a must

The lower level access you provide to a system, the higher the risk
that it can be broken in, and that break-ins will be of a more
critical nature.

> I think some form of 'access level' might be useful one day - e.g. the
> end-user can set a password to provide access to setting IP address while
> the manufacturer has a password for calibration and MAC address

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.

> These are all some basic random thoughts I have, but I think they
> illustrate that as the bootloader expands in functionality, the need to
> provide a measure of security also increases...

I disagree.  There are a large number of things that simply make no
sense in boot loader context.

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
What is tolerance? -- it is the consequence of humanity. We  are  all
formed  of frailty and error; let us pardon reciprocally each other's
folly -- that is the first law of nature.                  - Voltaire