Hi Wolfgang,
On 02/13/2012 06:31 PM, Wolfgang Denk wrote:
So basically you are suggesting to completely remove shell access in U-Boot which is one thing that make U-Boot so attractive.
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...
That is no less complex (and in the USB case actually much more complex) than what I was suggesting - In the dongle case you need to read and validate the dongle then flag to U-Boot that it is OK to enter command line
GPIO case is the same, you need to read the GPIO pin and if not set, skip entering command line
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
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
password = key. How are going to manage these?
I've said before, a hash of the password as an environment variable
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
You don't understand.
Adding security _always_ means removing certain "convenient" features.
Having a powerful, flexible tool that allows the user to do about everything and defining a secure environment where a specific user has only a well-defined set of capabilities are mutually exclusive by definition.
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
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 -
Use Linux, then.
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)
Ah! So your problem is that you want to do inappropriate things because your crappy, proprietary RTOS prevents you from doing the rights things.
No, not me - I'm not in that game. I'm just playing devils advocate because I know how these things work in the real world - GNU/Linux uptake is pitifully low :(
I'm sorry, but I don't commiserate with you about that.
Understood :)
And if the OS you used does not have a command line, you have to implement that on top - Often a non-trivial endeavour
It would be a totally wrong conclusion, though, to try to turn the boot loader in a wannabe OS just because it is more useful and capable than your RTOS.
There is no 'wannabe OS' about it - It is a simple 'enter a string->hash->compare' if equal, drop to command line, if not, loop back
If your RTOS does not stand to your requirements, then fix the cause of the problem, i. e. use a more capable OS.
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...
Agreed. Which is excatly why I prefer Free Software whenever it comes to security, crypto-technology etc.
100% Agree
Regards,
Graeme