k...@koi8.net a écrit : >>> Ah, that's absolutely orthogonal issue... We do NOT do something >> stupid from >>> engineering standpoint because it makes sense (and quite often it >> doesn't) >>> but because the regulations and the Commission's understanding of them >>> requires that. >>> >>> Yes, many of those are stupid and outdated but they do a good job >> anyways; >>> there is not that much cheating in our casinos. >> You seem to agree that a "secure boot" is maybe not more that only a >> marketing >> word... > > No, this does not have the same strict meaning as "#6-32x1/2" slotted head > steel zinc plated machine screw." It is a set of different features. Here > is e.g. a Freescale's whitepaper on one of their SoCs: > > http://www.freescale.com/files/32bit/doc/white_paper/IMX31SECURITYWP.pdf
This paper mainly describes hardware features that are not relevant for u-boot. The ROM authenticate a script that authenticate the boot loader (u-boot) that authenticate the firmware image (kernel and RO filesystem). The ability to update this system is controlled by a chain of asymmetric keys. It seem that the GPLv3 do not require to publish the private key if this is not a consumer product. I suspect that if a regulation exists for a product that require a security schema, then GPLv3 also do not force to publish the private key, but that must be carefully verified. In a more philosophical aspect, and as a customer, I can understand that some code are dangerous to modify and are secured, but there is a real issues that the security is also used to abuse the freedom to modify a system that don't require a high level of security. What you will do the day you can't find a computer that can't boot a Open Source system ? The GPLv3 is maybe right by requiring to allow to modify a system as long as this is not restricted by a regulation for safety reason. >> [...] >>>> Why do you think I want to fight regulation ? I actually be more >>>> concerned about understanding how a proprietary hidden piece of code >>>> into u-boot can possibly make a system satisfy a security >> regulation. >>> It is not just hardware/software. The latter is only a part of >> solution. It >>> is NOT the machine that pays that jackpot, it is real humans. There is >> no >>> way to make the system unbreakable and impossible to cheat on. That's >> why an >>> additional layer of security is being able to DETECT that system had >> been >>> cheated on. >> So why using open source at all if you think that hidden code is a way >> to make >> a system more secure ? It highly not consistent ! > > Who is talking about hidden code? It can be open source. And quite often it > is. And most of that code, BTW, is written by the people who are paid to do > it. If you want to make us drop U-Boot and write our own firmware no > problems, that's just additional job security for us. But don't expect all > those people to do anything on U-Boot and forget about their contributions. Pretty aggressive position. If I understand you correctly, there is already a asymmetric key authentication code to secure a firmware in u-boot. Please point out where it is because I can't find it in the last GIT tree. Regards, Jean-Christian de Rivaz _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
