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

[Graeme Russ <graeme.russ@gmail.com>]

Hi Mike,

On 02/11/2012 07:37 AM, Mike Frysinger wrote:

> waving your hands around and saying "doing XXX is more secure and therefore we 
> should do it" is theater.  i'm not against passwords or ASLR or anything else 

Agreed - I've already said as much in the ASLR thread

> in u-boot, but like Wolfgang said, let's see the realistic plan.

Well I might get back to this later

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.

Physical access (JTAG) can be detected by 'warranty void if removed'
stickers, so I would not be so concerned in this senario

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

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

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...

Regards,

Graeme