k...@koi8.net a écrit : > On Thu, 25 Jun 2009, Jean-Christian de Rivaz wrote: > >> k...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
