[U-Boot-Users] Re: [PATCH] ARTOS boot support for u-boot

[Wolfgang Denk]

In message <3E9FD3EE.4090402 at intracom.gr> you wrote:
> 
> The two level security is probably overkill, but a single
> level is necessary in my application.

This is already avaiulable right now - it's a config option. You  can
configure  U-Boot  such that you need to know the password to be able
to interrupt the autoboot procedure.

> >Don't allow any access to the U-Boot user interface, then. Run  a  OS
> >on  top  of  it, and implement a web interface or something like that
> >where the user actions can be controlled on a higher level.
> >
> Unfortunately the administrator or the support technicians need this access
> sometimes for troubleshooting, when the web interface is not available
> because of faulty network settings, or some network topology change.

Then give your administrators as much trainung and  documentation  as
is  necessary  to understand what they are doing, and to recover from
bad settings. For example, you can provide a script image which  sets
the  default  parameters,  and instruct your admins to "run defaults"
when necessary. This "default settings script image" can even be made
board-specific (if you use some automated mechanism to generate it).

There are so many options available right now - don;t  implement  new
stuff when just combining existing solutions is sufficient.

> >This has been available since long time ago. See "doc/README.autoboot".
> >
> I see nothing there about a password, and I'm aware of the autoboot feature.

Read the description  for  the  CONFIG_AUTOBOOT_KEYED  config  option
combined  with the CONFIG_AUTOBOOT_DELAY_STR config option and/or the
bootdelaykey environment variable.

They name might be a bit strange, but bootdelaykey == password.

> The passwords will be stored encrypted.
> 
> There will be no master passwords. If the password is lost
> a button pressed during the boot sequence, or a key sequence will
> reset the device state to that after it left the factory.
> It is then up to the administrator to restore the device to
> functional status.

If you have this reset option, then what's the problem at all with  a
dumb  admin  messing  with  the  settings? Let him reset the box, and
restore it to functional status.?


> At a site the passwords are the same for each device. It's not
> like each device will have it's own different password.

Sounds like "security by obscurity" to me.

> I don't intent to do that. I am not striving for maximum security,
> just a way to prevent non determined people of messing with their device
> out of boredom.

Then enable CONFIG_AUTOBOOT_KEYED in your consiguration (means add  a
simple  password  protection), and that's all. This will prevent most
things at low (zero) cost.

> Site security is a problem for the resident BOFH.
> I just have to provide him/her with the tools to do their job.

Keep it simple, though.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Deliver yesterday, code today, think tomorrow."