Dear Frans Meulenbroeks, In message <cacw_htbgtyclk380-fngt01132e+yq0hhw-54lfxh4mv7xt...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I paid too much for it, but its worth it. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
