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

[Jim Gettys]

On Sat, 2006-05-27 at 11:54 +0200, Carl-Daniel Hailfinger wrote:
> 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?

If it is generic USB failure, we're screwed anyway: the wireless is
interfaced over USB in this model.

There are 3 USB ports, so failure of a specific port doesn't cause
grief.

> 
> 
> > 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?

Dave says this flash doesn't have write protect bits. It was possible to
"write protect" sectors of flash on the iPAQ.  But the processor could
also "unprotect" the sectors, so it it was never a guarantee that the
boot loader could not be screwed up by a malicious program.

And yes, we still got "bricks" from time to time as people screwed up
reloading the bootloader or restoring WinCE to the devices.  We did get
it idiot proof enough that finally it was mostly WinCE restores that had
this effect (we'd only load bootloaders that had a particular checksum
signature into the boot sectors; this protected against loading other
things into the flash, and against errors in transfers to the machine
over serial links.

You'd be amazed how creative idiots are in screwing up their machine in
the process of updating it (I even did it once on the BIOS on my home
server mother board, so I'm as much an idiot as the next (though the
vendor's instructions were pretty horrid)).

> 
> 
> > 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 sequea

Exactly.

The serial ROM write protect is only enabled by the embedded controller
chip.  So long as that code is intact, we can require human intervention
before enabling rewriting the serial ROM.  This is the moral effect of a
write protect jumper, though I slightly vulnerable to Phishing attacks.

> "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.

Probably.  Please send me a note with your background and what you plan
to do.  Do you have the equipment to unbrick a machine (e.g. can use
JTAG to restore the flash)?  And I'd like to know what country you are
in for customs purposes, so I can give a heads up on customs we'll face
to Brightstar, who are handling logistics for us (addresses will go into
a web page at Brightstar for shipping).

> 
> 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.
> 

There are a couple answers to this question:
  o we may protect network services against day 0 attacks with SELinux.
  o there have been some suggestions around various certificate and/or
signing methods for verifying code.  I suggest conversations on this
topic take place on the security at laptop.org mailing list.
                                Regards,
					- Jim


-- 
Jim Gettys
One Laptop Per Child