Hi Wolfgang, On Mon, Feb 13, 2012 at 6:17 AM, Wolfgang Denk <w...@denx.de> wrote: > Dear Graeme, > > In message <4f378753.4070...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
