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

[Jean-Christian de Rivaz]

ksi at koi8.net a écrit :
> On Thu, 25 Jun 2009, Jean-Christian de Rivaz wrote:
> 
>> ksi at koi8.net a ?crit :
>>>> Please point out precisely the regulations that require secure boot.
>>>> Should be
>>>> trivial as regulations are by definition public.
>>> Do you happen to know what "Google" is?
>> Yes, thanks :-)
>>
>> For example this document have the term "secure boot":
>> http://www.dcg.virginia.gov/supplier/sup-rules/standards.shtm
>> The wording is this one:
>> "D. Electronic Bingo
>> [...]
>> 3.
>> [...] Security measures that may be employed to comply with these
>> provisions include, but are not limited to the use of dongles, digital
>> signature comparison hardware and software; secure boot loaders,
>> encryption, and key and callback password systems."
>>
>> The term "secure boot" is listed as a possibility, not as a requirement.
>>
>> Now I don't have the time to parse every possible document that Google
>> propose. This is why I politely ask a precise example, as I was under
>> the impression that some peoples know very well this subject.
>>
>>> This is our Nevada regulations:
>>>
>>> http://gaming.nv.gov/stats_regs.htm
>> I don't have the time to parse all the documents listed at this URL, but
>> I downloaded the one I suspect is the more relevant:
>> http://gaming.nv.gov/stats_regs/reg14_tech_stnds.pdf
>> And I cannot found "secure boot" into it.
> 
> Are you looking for a precise phrase?

I want to look deeper into the subject. I think that if a regulation
make a technical point as a requirement, then it must more or less
describe the technical point so that it can be implemented is a way it
work as expected. As an engineer, I think that a "secure boot" is only a
buzz word: if the system can be physically modified, it can't be
secured. If it can't be physically modified, then you don't need a
secure boot.

>>>> I failed to understand how a secure booted machine can be updated by
>> the
>>>> manufacturer to fix a bug for example, but not by a customer.
>>> The manufacturer can _NOT_ update his machine at will. _EACH AND
>> EVERY_
>>> change goes through the same approval process.
>> Still, technically the hardware have only two possibility:
>> 1) it can be reprogrammed.
>> 2) it can't be reprogrammed.
>>
>> If 1), I dont' see how the a boot loader can't be replaced by a less
>> secure one and let boot anything.
>>
>> if 2), there is not point as nobody can possibly make any update, so the
>> firmware don't have to be secured.
> 
> You are trying to make sense out of the regulations. It doesn't work this
> way. If regulations say "one must use a screwdriver with a red handle on
> this screw" one must use the red screwdriver. No matter if it makes sense or
> not. If you feel it's bullshit you should fight for the regulation to change
> that is a very long (years, not months) and very difficult process. In the
> meantime you _MUST_ use that red screwdriver.
> 
> Then you should read not only technical part but also a procedural one on
> how approvals are given. You must persuade the Commision to give you an
> approval. And they give them at their discretion. And you can NOT sue them.

In this second part, I don't make reference to regulation. I only talk
about the technical problem of reprogramming a system.

> Finally don't forget that your employees all want to get their salary paid
> and that comes from your business revenues. No approval == No business. Good
> luck fighting regulations.

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.

Regards,

Jean-Christian de Rivaz