The OLPC and BIOS upgrades

The One Laptop Per Child project will, if successful, place special laptop computers into the hands of millions of children all over the world. Most of these children will have never worked with a computer before. The consequences of providing Linux-based systems to this many children are likely to be huge. If this project is done right, these kids will grow up seeing free software as the preferred thing to use. Done wrong, it could turn them (and the adults around them) against Linux in a big way.

Many aspects of the OLPC systems are interesting; one of those is that they will use LinuxBIOS as their onboard, boot-time firmware. LinuxBIOS will bring a high degree of flexibility to the system, and some complexity as well. There is a real possibility that, as the result of some late bug or security problem, an in-field upgrade to LinuxBIOS will be called for. In addition, some users may want to hack on the firmware and install their own version - after all, the source is available. For both reasons, the OLPC systems will be able to rewrite their BIOS on demand.

There is a potential problem there, however. If it is too easy to rewrite the BIOS, no end of unpleasant things could happen. In the worst case, some sort of OLPC-based worm could, over a brief period, turn all online systems into expensive bricks. Or, perhaps even worse, the mass implantation of a low-level back door could be performed. For this reason, the OLPC design requires the user to give explicit permission before the BIOS can be rewritten. In particular, a specific sequence of keys on the keyboard must be held down before rewriting the BIOS will be possible.

Ivan Krstić has recently been thinking about the BIOS issue; in particular, he is worried that the keyboard-based interlock still leaves the system open to phishing attacks. The target user base for the OLPC, remember, will be very young. If something pops up on their screen telling them to push a certain set of keys, some of them may well do it. Adults may be immune to this sort of attack, but children need to be treated with more care.

So Ivan floated a proposal for a different way of doing things. It does away with the keyboard interlock; instead, the operating system is always forbidden to rewrite the BIOS. The BIOS, however, can rewrite itself, and would do so upon finding a new BIOS image in a specific place in the filesystem. That image would have to be cryptographically signed, however, so attackers would, presumably, be unable to get a new BIOS image written. Ivan says:

Some who responded were not entirely happy with this approach, however. The potential for performing BIOS upgrades (even if properly signed) without the user's knowledge or consent is troubling. If a bug is found in the signature verification code, the fully automated mass bricking scenario becomes real again. Users who want to put in their own version of the BIOS will be frustrated - they cannot be given the signing key without compromising the entire mechanism (though this problem can be mitigated through the addition of a unique key for each system). Some countries may be unwilling to buy and distribute the OLPC systems without the ability to create and install their own BIOS images. And so on; see the list archive for the full discussion thread.

There was no obvious consensus reached on the list - and no immediate decision to change the OLPC hardware design. It is an issue requiring some additional thought, however. The OLPC systems are designed, in general, to be easy to fix when a user breaks things - they are meant to be experimented with. A BIOS-level bricking, however, is decidedly not easy to fix; it is not a scenario which can be allowed to come about. So it will be interesting to see what solution the OLPC designers arrive at in the end.

(Update: the OLPC project has decided to implement the new mechanism as originally described in the article).

---

to post comments