On 22.05.2008 17:01, C. Scott Ananian wrote: > On 5/22/08, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > >> > h) hardware-protected RTC (bitfrost desiderata) >> I'd be very interested in the reasons for that. P_THEFT is still mostly >> unimplemented for cost reasons. A hardware-protected RTC will not >> improve the current state at all as long as the hardware side of P_THEFT >> is not implemented. It will certainly raise cost, though. >> > > Not the case: epoxy-coating the motherboard was not cost-effective, > meaning that the cost of bypassing P_THEFT by circuit-board changes > was already expensive enough to be infeasible -- and of course epoxy > adds to manufacture, repair, and rework costs. The economics weren't > with it. >
As I stated before on this list, bypassing P_THEFT is very easy. You don't even have to desolder the complete flash chip, one pin is sufficient. All of this is doable for less than $1 per laptop if you have access to cheap labor. $1 per laptop is _not_ expensive enough to be infeasible. I am very willing to publish a video tutorial of the procedure if you think I can't do that. The only downside would be that everybody then knows how to bypass P_THEFT. > We actually know exactly how much it costs to bypass P_THEFT in bulk, > since some of original manufacture run ended up with a firmware bug > which bricked them in exactly the way P_THEFT would. > If you came up with a cost of more than $2, the recovery/bypass was missing the obvious shortcuts or you had a requirement not to solder. > Hardware-protected RTC helps with the security of ongoing > theft-deterrence, which is orthogonal to initial activitation security > (which it seems you are discussing). Agreed on the orthogonality. > Contrary to your claim, initial > activation security is being heavily deployed and does seem to be > successful. > A statement of security is a nice theft deterrent. This may change once the bad guys realize circumvention is very doable. >> > i) better protection for firmware FLASH, to avoid the possibility of >> > bricking a machine if the power is removed at the wrong time. >> >> Protection for firmware flashing against bricking is easy if the flash >> chip is big enough. OTOH, performing an update of EC microcode is a much >> more difficult thing to protect against failure. >> > > Yes, there were some design details with Gen 1 hardware that turned > out to make it difficult to safely reflash, even though the flash chip > is big enough to accomodate a backup OFW. The EC is perfectly capable > of recovering OFW, but the EC memory map coincides with the erase > block size of the SPI flash, unfortunately, so there's a critical > window during which all of the EC code must be erased. We hope to fix > that with Gen 2. > There are SPI flash chips on the market which have an erase granularity of half the size of the EC code or even less. Selecting such a chip should work even for Gen 1 unless I'm missing a key detail. >> > k) more open software: we may not need an EC, and if we do we may be >> > able to ensure its code is open. We may change the wireless device, >> > and/or be able to switch to open firmware for it. >> >> I believe item k) was already in the contracts with Quanta and Marvell, >> unless the official announcements back then were wrong. It has been >> stated repeatedly by OLPC officials that the only thing preventing a >> full open source wireless firmware is the lack of time for porting the >> code to another embedded OS. There were also statements like "We are >> working with Quanta to release EC source code", so I think that's also >> mostly a problem with lack of time. >> > > Yes, it was intended, but the production schedule and component > availability forced us to build on some pre-existing closed-source > components, and now that we've reached this point in the manufacturing > cycle for XO-1, we have very little leverage left with Quanta. We did > make our best effort, but there were also some unforeseen interactions > with the manufacturing contract we signed with Quanta. Quanta > designed the motherboard and took responsibility for making > modifications for manufacturability and to address defects, and now > they've ended up with significant IP rights in our schematic. This > has made it hard to properly support the open EC effort, since by the > terms of the contract we can't even show them the pinout of the EC. > We recently hired Paul Fox as firmware engineer, so we're still hard > at work on this. We hope that we can work out agreements with Quanta > to publish at least pinout information for the EC. It's complicated > by the fact that most of Quanta's team working on the XO-1 design has > moved on to other projects now. > That's really a nice writeup of the current situation. Could you please put it (perhaps even verbatim) into the wiki and link it from the EC and OpenEC pages? Thanks! > The http://www.open80211s.org/ effort is being funded by OLPC to try > to address the wireless firmware issue (among other goals). I don't > really know what mesh solutions are being considered for XO-2, but > there are more vendors with 802.11s solutions now than there were when > we designed the XO-1, so we have more choices and leverage. > That's good to hear. Again, adding this info to the wiki would help public perception a lot. Regards, Carl-Daniel _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel