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

[Wolfgang Denk]

Hi,

in message <3E9FA26F.3000906 at intracom.gr> you wrote:
> 
> We already use an OS. The problem is that the device's user/person who
> has physical access to it, is not supposed to be allowed to alter anything
> in the configuration; especially the network settings, since an error there
> will render the device unoperable.

In my opinion U-Boot is not the right user interface  for  such  use,
then.  It  is a monitor program / boot loader, the intention of which
is to provide direct access to the hardware. And with  direct  access
to the hardware you can easily work around security measures.

For example, will you disable memory dump/modify  commands?  Probably
not,  as  they  are  very useful to the user. So what prevents a user
from using "mm" or "mw" to directly modify the working  copy  of  the
environment variables in RAM?

I don't know what you want to do, but IMHO you can either prevent use
of the U-Boot command line interface completely, or you will have  to
live with the fact that a user can do things he should not do.


"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn


This applies for U-Boot, too.


> Think access control on a router or something similar.

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.


> True, it's a problem on how to implement it cleanly. We'll see how that 
> will
> turn out. A first simple step will be to have a single password for
> entering the command mode.

This has been available since long time ago. See "doc/README.autoboot".


A relatively unintrusive method couldbe to  change  the  "repeatable"
field  in "struct cmd_tbl_s" into a "flags" field, where 'repeatable'
is just one bit, and one (or more) other bit(s) are used to specify a
"security" level, to prevent  the  command  from  being  run  if  the
security level does not match.


> Almost nothing actually, it's just a method of managing the existing 
> settings
> by using a master switch.

I'm afraid this won't work as you  expect.  You  will  either  render
U-Boot  useless,  or  add  "security"  which  in fact is just window-
dressing.

You allow execution of any some, but not all  commands?  Be  careful,
even simple commands can be used to do "critical" things.

I don't need "setenv" to modify the environment. "mm" or "mw" will do.

I don't need "saveenv" to store the settings. "cp" or "eeprom  read",
"mm" or "mw", "crc32" and "cp" or "eeprom write" will do.

How do you save ypour passwords? Unencrypted in the  environment  (as
it is now the case) ? Guess how long I will need to find them!

You will add encryption? How will you manage passwords onthese  boxen
then,  in case the password was lost? Ah, you will implement a secret
master password? OK, I'll look it up in the source  code.  [And  you,
you MUST provide the full source code, this is GPL software.]


Sorry, but I really see no easy way to harden a box if you  open  the
U-Boot  command  line  interface  to  a customer. Change your design.
Don't use a chainsaw for jigsaw work.

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
Niklaus Wirth has lamented that, whereas Europeans pronounce his name
correctly (Ni-klows Virt), Americans invariably mangle it into (Nick-
les Worth). Which is to say that Europeans  call  him  by  name,  but
Americans call him by value.