[U-Boot-Users] Re: [PATCH] ARTOS boot support for u-boot
wd at denx.de
Fri Apr 18 11:58:35 CEST 2003
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
> 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
> 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-
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.
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.
More information about the U-Boot