[OLPC-devel] just verified: 2306 + olpc + linux kernel works.

[Carl-Daniel Hailfinger]

Jim Gettys wrote:
> I'll be satisfied if there is *one* iron-clad recovery method that does
> not depend on the NAND flash.  If it is copy from a USB key to the
> flash, so be it.

That decision may save us >250k of BIOS flash. We can probably save
more if we depend excessively on the NAND flash drive for booting,
but OTOH we do not want to make breaking the bootloader too easy.

How will we handle hardware failures of the USB port if it is the
only way to revive a system?


> As far as I'm concerned, we can go wild on other games for convenient
> booting and wireless install in a partition on NAND once we've assured
> the one recover mode that does not depend on it.  So we can certainly
> load modules, have additional code in NAND to make life easy.  And we
> can make that flash unwritable (to first order).  

You mean we can make a small part of the "hard drive" permanently
unwritable? If so, won't this write protected part suffice as recovery
base?


> It's just the internet virus making the machines require jtag for repair
> that makes me not sleep.

Rest assured that we work hard to make sure such a thing is impossible.
However, please be aware that I see it as a personal challenge to find
ways to circumvent this protection *BEFORE* these systems are deployed
and tell this list about the results. We can't formally verify the
protection against bricking, but second best is a clean design and trying
to break it.


> The flash on the iPAQ had bits you could set that would write protect
> sectors of the flash (does the NAND flash we have have similar
> capabilities?  I dunno). That meant you couldn't write from Linux
> without first unprotecting those sectors

If unprotection can be done in software, you have lost. Somebody will
eventually figure out the correct sequence and get famous by bricking
thousands of machines.
"Set this bit and flash will be write protected until hardware reset"
is NOT sufficient even if we decide to set such a bit in LinuxBIOS.
See the Intel CPUID disabling disaster for details.

Can I have one of those development boards to make sure it can't be
bricked via software? I promise to be creative.

Oh, and another question: Is anyone looking at the network security
side of these laptops? I see endless possibilities for abusing all
those innovative networking features.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/