Dear Graeme,
In message 4F38F91D.6070301@gmail.com you wrote:
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...
USB dongle is definitely on the far end, but why not - if you have such a sort of S & M preferences ;-)
Normally a jumper or DIP switch would be used - which is trivial to implement.
GPIO case is the same, you need to read the GPIO pin and if not set, skip entering command line
Which is trivial. Just implement the test in misc_init_r(), and use this to set bootdelay to 0 or -1 or similar.
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
I understand your proposal, and actually we already have that! See the documentation in doc/README.autoboot
But you were talking about security - guess how many of such systems will all run with the very same password? And guess how long it will take until it is publicly known?
Even if you extend this feature to store only a hash of the password, and compare the hashes, the fundamental problem will remain: How can you precent that the passwords get faster pblicly known than you can change them?
What do you do in case the user forgets the password? Will he have to return his box for repair or even replacement?
Of will there be some additional "master password" which is only known to your field circus engineers (and after a few days to all hackers in the whole world)?
password = key. How are going to manage these?
I've said before, a hash of the password as an environment variable
This does not answer how you intend to handle the obvious problems - see above.
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
You trade one problem for another. Guess how many users will call service because they have forgotten their password settings?
Best regards,
Wolfgang Denk