From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Christian de Rivaz Date: Thu, 25 Jun 2009 23:44:54 +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> Message-ID: <4A43EFD6.4000005@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 : >>>> 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. > > It is not just technical measures; it is a complex of them and different > operating procedures. Yes, I known that. But here we specifically talk about u-boot. You still failed to show a description of how u-boot can be modified to secure a system and why this must be a hidden proprietary code. >>>>>> 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. [...] > 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... [...] >> 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 ! Regards, Jean-Christian de Rivaz