[U-Boot] U-book and GPLv3? (fwd)

[Jean-Christian de Rivaz <jc@eclis.ch>]

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