Dear Graeme,
In message 4F378753.4070808@gmail.com you wrote:
Do not do this in the boot loader. It is not the environment for such things. When it comes to security, you are automatically pulling in things like encryption technologies, key management, etc. We do not want to pull this into a bootloader - it would just be a poor mans surrogate for a real OS. Instead, do the logical step and use a proper OS that provides all these things for free, in a well-tested and protected environment.
The issue is that the bootloader has complete access and control of critical hardware components (Flash, environment storage, MAC address etc) and at the moment there is no effective protection.
There is nothing that a boot loadr can do, that cannot be done as well by appropriate Linux kernel code.
If all the bootloader did was transition to the OS without any support for an interactive environment then the would not be a problem (aside from hacking the hardware, but there is no way a bootloader can protect against that anyway, so the point is moot)
It is way easier to prevent a user from getting any interactive access to the boot loader at all than it is to protect such access by a password and open it only for "priviledged" users/
Suitable encryption is already in U-Boot (we have SHA and MD5 libraries already)
We have only checksumming. We do not have any kind of key management whatever.
I disagree. There are a large number of things that simply make no sense in boot loader context.
I would agree if the bootloader did not have an interactive environment for providing low-level access to things that need to be protected. But U-Boot provides just that (and it is part of the reason so many people use it).
You don't have to open access to such "things that need to be protected". It is way easier not to provide such access at all then to try and protect it with a password.
By having these function in the bootloader: a) The functionality is already there - they don't have to implement it (which may be practically prohibitive for some CoTS embedded OSs) a) They don't have to go all the way into the OS to use the functionality b) They don't have to put those functions in the OS and thus provide a potential security concern (if tools to modify the low-level environment are not in /sbin/ then gaining root access by a buffer overrun is not so serious)
Sorry, but I really cannot follow you.
So you either do not implement any 'critical' functions in the bootloader (realistically that may mean not providing a command line at all) or secure the bootloader to the same level as the OS
Correct - in a protected environment I would not provide any interactive functionality for U-Boot at all. Everything else is _way_ too easy to break in.
Best regards,
Wolfgang Denk