G1G1 laptops are shipping with "security" enabled

[gnu]

There is no reason to have DRM enabled in the manufacturing tags of G1G1 laptops, yet they are apparently being shipped this way. This requires each recipient to request a development key before they can run unapproved open-source software on their laptop.

For example, in #4286, Mako stated: "...the anti-theft system will not be deployed for the G1G1 laptops...".

One of the standard problems with DRM is that it creeps from the places where it's wanted, into places that don't want it or where the owner actively dislikes it. TiVo owners periodically report that some TV shows are marked as "don't save", despite the avowed intent of that feature to be latent and disabled (til later!); see

http://www.news.com/TiVo-copy-protection-bug-irks-users/2100-1041_3-5863529.html?tag=st_lh

OLPC's firmware "security" was pitched as an "anti-theft" solution, ONLY for countries that require a machine stolen from the schools to become a brick. But here it is on laptops bought for individuals, who neither asked for nor require "protection" from themselves! OLPC's DRM can be disabled, which makes this non-fatal, but OLPC users should not have to jump through that hoop.

My G1G1 laptops will probably be shipped in late January, and I hope not to receive DRM'd units. I bought these laptops with the expectation and assurance that they were at least as open as white-box PC clones that will boot whatever software you throw at them. If this bug is caused by a bad manufacturing tag setting at the factory, the fix should be rolled into ongoing production.

[gnu]

Date: Mon, 24 Dec 2007 20:11:36 -0500

From: Mikus Grinbergs <mikus@…>

To: devel@…

Subject: Re: Is DRM on every G1G1 laptop?

http://wiki.laptop.org/go/Developer_Key describes the procedure for obtaining a developer key. We tried to make that procedure as easy as possible within the constraints of our available manpower and time (i.e. we have a lot of other things that need attention too). Note that there is no discretionary component to this procedure - ask and you shall receive.

I now have my developer key - thank you very much. But there were hurdles:

The procedure describes using 'wget' to fetch the key. Perhaps due to my physical connection setup (wired + proxy), the 'wget' would time out and say "Resolving activation.laptop.org ... failed". [Note: for me, wget on the laptop *does* work when fetching from other olpc servers. And Browse on the laptop *did* fetch (from activation.laptop.org) the "status" page associated with my key.]

I ended up using a browser on a regular Linux system to fetch the key. [And I had to twice override the browser, which kept telling me it did not trust the activation.laptop certificate.] Then I had to provide a way to transfer the key from the Linux system to the laptop (to match how the other systems on my local LAN communicate, I installed vsftpd on the laptop). A lot of effort.

mikus

[jg]

Is it acceptable to you that your laptop be able to be "bricked" by a virus or worm, as conventional whiteboxes are able to be?

I agree we need to make the developer key stuff better, it is way to painful right now....

[cscott]

I requested debugging details from mikus on the devel@ list, including the output of wget with the -d (debugging) flag. Unless he provides more information (to date he has not) I cannot reproduce or address his problems.

Reassigning to jg, as this is clearly a political issue, not a functional one.

Open separate bugs if you want to (a) fix wget for mikus, or (b) discuss improvements to the dev key process (which are blocked by getting files from Browse to arbitrary places on the filesystem; hence involve both UI and security concerns).

[cscott]

Replying to cscott:

(b) discuss improvements to the dev key process (which are blocked by getting files from Browse to arbitrary places on the filesystem; hence involve both UI and security concerns).

OK, I've opened #5709 and #5710 for this issue.

[gnu]

Replying to jg:

Is it acceptable to you that your laptop be able to be "bricked" by a virus or worm, as conventional whiteboxes are able to be?

Totally, absolutely, 1000%. It is much better for theoretical future malware to theoretically brick a laptop in the future, than for its manufacturer to actually, physically brick it today. You've burned the village to save it.

Hundreds of millions of whiteboxes are in active use daily. Very few are ever bricked by malware. The D*M in the XO is bricking laptops every day for real live donor/customers, including a lot of little kids' Christmas presents.

I supported four such people yesterday, one in IRC and three in rt.laptop.org. In some cases the machine isn't necessarily bricked, but it can't be diagnosed because you can't interact with it.

Please don't conflate D*M with security against malware. It's not clear to me exactly how malware could brick a laptop (other than by writing zero to the RTC month register, triggering a firmware bug). It should be easy for the firmware to disable writes to the firmware flash chip before booting any kernel (whether tagged "wp" or not). This would still allow writing the firmware from Forth, which is how we always do it anyway, but not from Linux. Closing off that opportunity for malware has nothing to do with whether the user is permitted to type commands to the firmware before receiving a blob signed by a private key held by OLPC.

[jg]

There are registers you can write that will write the flash on our, or most any other machine. This isn't just against malware.

You don't seem think this can happen: but I've done this personally to my white box at home (I updated the boot flash on my white box with the compressed version of the firmware, rather than the uncompressed version, and the firmware writing program had no checks to prevent it.) One bricked mother-board.... And I like to think I'm less likely to do this than most people.

In short, on most machines, if you have root, you have the ability to "brick" your machine. At best, one can call avoiding this as security by obscurity.

Note that it appears some of the problems you've been helping with happened for a different reason: a bug Mitch had in firmware before D07, where a bad month field interacted badly with the security system.

I'll chat with Mitch on the suggestion you make in the final paragraph of your reply....

[jg]

OK, here's the order of march I see on this topic, having chatted with Walter on the topic, and looking at engineering resources available, the fact the G1G1 systems have already shipped and we can't change everything overnight.

1) Our highest priority has to be to streamline getting developer keys; it is currently too painful, and affects everyone, G1G1 or kids, teachers and country deployment people all over the world. It is causing a support burden we need to avoid, and is operationally painful; it appears our browser's security settings and lack of sophistication in certificate handling in recent builds may be compounding the headache further

2) We need to be able to preserve developer keys across image reinstallations, by preserving the key in flash rather than requiring recording the key or requesting a duplicate, so that we no longer multiply the effort 1) presents to both developers and to people supporting developers.

3) Protecting the firmware against malware kernel level attacks or accidental rebricking (as has happened to me personally; I'll bring in my junk whitebox motherboard and put it on my wall as a trophy) even when unlocked by a developer key is also worth doing, but lower priority than 1) and 2).

How much of this we can get done by even Update.1 is less than clear to me, given constraints on time and manpower.

Once we've done these, we can have a discussion about what we might do in future G1G1 programs as to settings, and where the right line is....

[gnu]

As part of 1) "streamline getting developer keys", installation of the key on the laptop should be automated. Currently it requires WRITING DOWN a long wget command line, including a long random URL, then switching to a root console, then typing it in (without errors) and running it. Then rebooting, then interrupting the reboot and typing "disable-security", which tells you to do it again after the reboot, then interrupting a second reboot and typing "disable-security".

The installation of the key in the NAND filesystem should happen in the web browser, when the key is available from Central Services. We may be stuck with the double reboot -- or perhaps, on its way down for the first reboot, OFW can notice the devkey in NAND and avoid locking the SPI flash.

At the very least, we could get copy/paste working in the $&#&@# web browser and terminal emulator, so the user could avoid finding a pencil and paper (and learning to write, for the children involved) to copy a command from Activity A to Activity B!

[cscott]

I believe copy and paste from browser to terminal work in update.1. I don't know anything about whatever certificate bugs jg is complaining about in his item 1. jg's item 2 is presently infeasible, for a number of reasons. A better solution is to use 'disable-security' if that is what you want to do, which is what gnu recommends in his reply. Even better: keep using olpc-update, which has no problem preserving the key. No idea what jg means by item 3; we already protect against access to SPI flash access even with a dev key, which is what causes the reboot cycle gnu complains about.

The "automatic installation from web browser problem" is out of my court: stuff downloaded from the browser ends up in the journal and the journal needs to grow some special knowledge of dev keys and put them in the right place. Please file a separate bug for that, and assign it to the journal guys.

[wmb@…]

http://dev.laptop.org/ticket/4397 also affects the need for a reboot . The technique that the OS currently uses to reboot does not open the SPI write latch, so the firmware must perform an additional reboot before it can do the SPI FLASH update.

[gnu]

Replying to cscott:

The "automatic installation from web browser problem" is out of my court: stuff downloaded from the browser ends up in the journal and the journal needs to grow some special knowledge of dev keys and put them in the right place. Please file a separate bug for that, and assign it to the journal guys.

Well, actually, developer keys do not end up in the journal. The page that comes back from activation.laptop.org doesn't include a link to the developer key, so the user can't download the key using the browser. (The page includes a command line which you are encouraged to write down and then type to a root shell.)

So, the page that tells you about your devkey should also include a link to the develop.sig file itself. Then, the Journal developers will be able to test their changes.

[gnu]

Replying to cscott:

I don't know anything about whatever certificate bugs jg is complaining about in his item 1.

The problem is that our https: site is signed only by our own cert, which nobody else's browsers (nor their wget) know the public key for. We should consider also signing the site with a cert that has widespread acceptance.

jg's item 2 is presently infeasible, for a number of reasons. A better solution is to use 'disable-security' if that is what you want to do, which is what gnu recommends in his reply. Even better: keep using olpc-update, which has no problem preserving the key.

When OFW first sees a valid developer key, it could copy it into the manufacturing area as a new tag (dk). This would provide more permanent stability for the key, independent of changes to the NAND filesystem. It already does something similar if it finds a signed firmware file in the NAND.

Unfortunately, the support crew often encounters XO users whose symptoms indicate that the NAND filesystem seems to be fried for one reason or another. The recommended advice (unless there's significant saved data that the user wants to keep) is to reflash from scratch using the "Activated Update" or "four-game-key" procedure. This may be an infant mortality problem; it's too early to tell how often such a reflash will be the easiest recommended way to get your laptop back in the future. But OLPC expects to be shipping millions of infant XO's every year. We appreciate your olpc-update tool, Scott, but it's not the right hammer for every job.

No idea what jg means by item 3; we already protect against access to SPI flash access even with a dev key, which is what causes the reboot cycle gnu complains about.

JG fried a motherboard on a white box PC by reflashing once, and has a visceral memory of that experience. I had suggested an improvement to our SPI index gating strategy that would prevent host accesses via indexed-IO after Linux boots, even in WW-tagged machines. This would restrict tag and firmware changes to ONLY ever be done from Forth. However, Richard Smith might object to that; he has battery diagnosis and repair scripts that might suffer. Also, this might mess up the process flow in manufacturing, if they have Linux code that's writing tags. At any rate, it's a subject for a separate TRAC ticket.

[cscott]

Please file specific bugs wrt dev key installation, etc. Most of these are already handled by trac bugs already assigned to me; please check these before you file a dup.

[gnu]

OLPC is now running a new G1G1 program and has made the same stupid mistake (shipping them with "security" DRM enabled). This is WONTFIX with a vengence. You'll start hearing the screaming soon, from people who try to install the F10 SD card on it, or debxo. It should still be fixed.