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

[Graeme Russ]

Hi Wolfgang,

On 02/13/2012 06:31 PM, Wolfgang Denk wrote:

>> So basically you are suggesting to completely remove shell access in U-Boot
>> which is one thing that make U-Boot so attractive.
> 
> 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...

That is no less complex (and in the USB case actually much more complex)
than what I was suggesting - In the dongle case you need to read and
validate the dongle then flag to U-Boot that it is OK to enter command line

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

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

>>> We have only checksumming. We do not have any kind of key management
>>> whatever.
>>
>> Why do we need key management - We aren't doing any decrypting (I'm not
>> suggesting 'Secure Boot' here). All we are doing is comparing two
>> passwords which we can use secure hashing functions like SHA or MD5 for
> 
> password = key.  How are going to manage these?

I've said before, a hash of the password as an environment variable

>>> 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.
>>
>> Again, you are suggesting removing functionality that attract people to
>> U-Boot
> 
> You don't understand.
> 
> Adding security _always_ means removing certain "convenient" features.
> 
> Having a powerful, flexible tool that allows the user to do about
> everything and defining a secure environment where a specific user
> has only a well-defined set of capabilities are mutually exclusive by
> definition.

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

>> If you buy a CoTS OS for your embedded system, it may not come with a
>> command line, let alone the tools already provided in U-Boot. So you then
>> have the additional development cost of implementing all those features -
> 
> Use Linux, then.
> 
>> fine if your firmware is open source (you can just use the U-Boot code) but
>> if those features need to be integrated into the CoTS source code, you have
>> to go it alone (most PLC/RTU CoTS OSs are just a library that you link in
>> your code to produce a single, monotomic binary so using GPL code is out
>> of the question in those cases)
> 
> Ah!  So your problem is that you want to do inappropriate things
> because your crappy, proprietary RTOS prevents you from doing the
> rights things.

No, not me - I'm not in that game. I'm just playing devils advocate because
I know how these things work in the real world - GNU/Linux uptake is
pitifully low :(

> I'm sorry, but I don't commiserate with you about that.

Understood :)

> 
>> And if the OS you used does not have a command line, you have to implement
>> that on top - Often a non-trivial endeavour
> 
> It would be a totally wrong conclusion, though, to try to turn the
> boot loader in a wannabe OS just because it is more useful and capable
> than your RTOS.

There is no 'wannabe OS' about it - It is a simple 'enter a
string->hash->compare' if equal, drop to command line, if not, loop back

> If your RTOS does not stand to your requirements, then fix the cause
> of the problem, i. e. use a more capable OS.
> 
>> Better that the security be developed, analysed and maintained by a large
>> group of open eyes than trusting your dev group of maybe two or three
>> people get it right...
> 
> Agreed. Which is excatly why I prefer Free Software whenever it comes
> to security, crypto-technology etc.

100% Agree

Regards,

Graeme