[LinuxBIOS] OLPC Keyboard/System Controller ENE KB3920

Jim Gettys jg at laptop.org
Wed Mar 15 05:32:46 CET 2006

On Tue, 2006-03-14 at 21:58 -0600, Bari Ari wrote:
> Jim Gettys wrote:
> > It isn't clear to me if we should release the code (at least without
> > some thought) to this part.
> If it would help with "The Free Software Foundation's Campaign for Free 
> BIOS" for laptops
> http://www.fsf.org/campaigns/free-bios.html

I'm aware of the campaign.  I guess I'm more on the pragmatic Linus side
of the camp: my interest in LinuxBIOS is what it can do that we forsee
difficult or impossible using a conventional BIOS. LinuxBIOS looks to us
like *the best tool for our job*. I personally believe open source and
Free software should meet all comers on its own merits; the ideology is
secondary or tertiary in my view. I'm not saying I don't share much of
what the FSF advocates; I'm saying that by free software being the
obviously right technical solution to a problem is an even stronger,
cogent, compelling argument than ideology.

We have a secondary motivation that is educational: we'd like kids to be
able to take the software apart down to the bare silicon as a potential
learning experience: you can't do that on closed source BIOS's.

But if the commercial BIOS did all of what we need (and you aren't yet
aware how interestingly nuts we've all become, yet), I'd use it.  But
they don't, and LinuxBIOS means we can get in there and make whatever
changes are needed, and we know we need changes that go beyond the
usual.  When you fully understand what the DCON chip means, you'll have
an interesting revelation.  I'll guess we'll open up on that in a week
or two; definitely by the Linux Power management summit in April.

> OLPC would also gain support from this community and the whole open 
> source community for laptops and tablets.
> The keyboard/system controller in laptops is often used to control 
> writes to the flash (and several other system areas) and has made it 
> very difficult to support laptops with a Free BIOS.

Actually, I suspect we may end up with a separate keyboard controller to
save on wires.  The spec current calls for the keyboard to be
electrically PS/2.  That implies a separate keyboard scanner, or many
wires have to go through the hinge.

> > 
> > Here's what I'm paranoid about: that the serial flash rom in which
> > LinuxBIOS  and bootloader is stored gets overwritten, and the laptop is
> > no longer a laptop, but an expensive brick.  I particularly worry about
> > someone writing a worm that manages to do this, and that
> > thousands/millions of machines all over the world are unrecoverable.
> > The logistics of repair are impossible.  I will ask Mark Foster about
> > how that flash gets write enabled; if we can absolutely in hardware
> > inhibit write to the boot flash, then I get much less worried.  I've
> > sent him mail asking.
> Several vendors have relied on "security through obscurity" to prevent 
> worms or a virus from modifying the system BIOS. It's always been 
> defeated. A very difficult AES + SHA-1 or SHA-256 hash based security 
> scheme could be used, but it still would not be 100% secure.

I don't believe in security by obscurity.

I have asked Mark Foster to see if he can determine a way to write
protect the flash; he said he'd see what he can do.

Bullet proof solution is what we have to have. "Takes a licking and
keeps on ticking" as the old Timex commercials said (boy, I'm showing my
age, aren't I?

> > I do want the bootloader sequence in this flash to be able to load a
> > second copy of itself out of the regular main flash so that later
> > versions can be installed safely (with appropriate checksum checking).
> > I don't want the situation we had on the iPAQ where you could possibly
> > "brick" the unit when updating the bootloader.  The iPAQ valhalla we had
> > (you could send us a bricked iPAQ and we'd eventually reflash it via
> > jtag and return it) was a PITA, and not feasible for OLPC.  We have to
> > ensure boot and restore is absolutely bulletproof.
> > 					- Jim
> Fallback BIOS in ROM plus a hardware switch/jumper to control writes to 
> flash is one 100% solution. Having a fallback BIOS image in flash would 
> only be safe if writes to the memory area in flash that stores the 
> fallback BIOS image is completely inaccessible to writes unless a 
> hardware switch/jumper is enabled.

External switches cost money and are difficult to seal.  Internal
jumpers we may be able to afford.

As I said, I am hopeful we'll make the flash unwritable.  Then I can
sleep at night...
				- Jim

Jim Gettys
One Laptop Per Child

More information about the coreboot mailing list