Dear Frans Meulenbroeks,
In message CACW_hTbGtYCLK380-FnGT01132e+yQ0Hhw-54LFXh4mV7XTr2g@mail.gmail.com you wrote:
Generally speaking there is a use case for a password.
Of course there is. The question is if the oot loader is the right place for it.
E.g. if you deliver boards/systems with u-boot on it and you do not want customers to enter u-boot (e.g. by accident or because they want to hack the board), but you would allow authorized service personnel to access the board.
For this case a secret password in the image would probably suffice (guess it might help to have it encrypted in flash or store a hash or so. Of course is the password leaks the security is gone.
Right. And we don't have anything like login names or users or priviledges in U-Boot, so all systems you ship would use the same master password. And the source code is under GPL and visible to everybody. Guess how long your "security" lasts?
If you want security, then don;t allow access to U-Boot at all, and run an OS. There you can do fancy things, including password protection.
A password in env is more hackable. It would at least require no access from the kernel to the section the env is in (so no userspace tools and no /dev/mtd0 mapping to the whole flash).
Yet another alternative (probably solution specific, is to store the passwd in a separate eeprom or so and make sure it is not accessible from the kernel (not always trivial)).
Do you realize that you are already talking how to maintain this "security" level in Linux? Then also implement it there! That's where such stuff belongs to.
Best regards,
Wolfgang Denk