In message 3E9FD3EE.4090402@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