From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Christian de Rivaz Date: Fri, 26 Jun 2009 11:03:12 +0200 Subject: [U-Boot] U-book and GPLv3? (fwd) In-Reply-To: References: <20090618145128.69F27832E416@gemini.denx.de> <12fb2e608911e671661778990f2f793e.squirrel@webmail.plus.net> <200906251000.17822.vapier@gentoo.org> <4A43A0C9.8090009@eclis.ch> <4A43CB93.80206@eclis.ch> <4A43DC8C.3080109@eclis.ch> <4A43EFD6.4000005@eclis.ch> Message-ID: <4A448ED0.5030409@eclis.ch> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de ksi at 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