Hi Wolfgang,
On Mon, Feb 13, 2012 at 6:17 AM, Wolfgang Denk wd@denx.de wrote:
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.
Yes, but that access can be controlled through logon credentials after the OS has been loaded.
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/
So basically you are suggesting to completely remove shell access in U-Boot which is one thing that make U-Boot so attractive.
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.
Why do we need key management - We aren't doing any decrypting (I'm not suggesting 'Secure Boot' here). All we are doing is comparing two passwords which we can use secure hashing functions like SHA or MD5 for
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.
Again, you are suggesting removing functionality that attract people to U-Boot
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.
If you buy a CoTS OS for your embedded system, it may not come with a command line, let alone the tools already provided in U-Boot. So you then have the additional development cost of implementing all those features - fine if your firmware is open source (you can just use the U-Boot code) but if those features need to be integrated into the CoTS source code, you have to go it alone (most PLC/RTU CoTS OSs are just a library that you link in your code to produce a single, monotomic binary so using GPL code is out of the question in those cases)
And if the OS you used does not have a command line, you have to implement that on top - Often a non-trivial endeavour
So now you have implemented your own 'low level commands' and possibly your own command line - How do you know it is secure. You now have to implement some kind of secure access (a password!) to protect access to those functions - functions already provided by U-Boot which would not be too difficult (IMHO) to secure - A simple 'gate' where U-Boot drops into command line mode requiring a password who's hash matches the hash stored in an environment variable
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.
Better that the security be developed, analysed and maintained by a large group of open eyes than trusting your dev group of maybe two or three people get it right...
Regards,
Graeme