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

[Frans Meulenbroeks]

2012/2/11 Graeme Russ <graeme.russ at 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...
>

Graeme, if you want to keep people outisde the bootloader in a
reasonably safe way and are developing your own hardware an option is
to put the password in e.g. an eeprom and do a compare in u-boot.
Of course a persistent hacker could retrieve the password but a casual
user will not be able to enter.
Having the password in eeprom makes that it is not disclosed with the
code, it can be changed etc. Just make sure users do not have easy
(sw) access to the device the password resides in, so e.g.disable
access one way or another.

One other way to prevent accidental access would be a jumper. If
present no access to u-boot possible at all, if not present access is
possible. And some stuff on it to view if it is tampered with.
(if the jumper raises or lowers a gpio device on an i2c chip this can
be easily detected in a u-boot script and depending on that action
could be taken).

My two cents.

Frans