4 things you (probably) didn't know you can do with Chrome for Linux

@All:

http://www.chromium.org/chromium-os/chromiumos-design-docs/security-overview

Quoting:Rendering pwned devices useless: We do not intend to brick devices that we believe to be hacked. If we can reliably detect this state on the client, we should just initiate an update and reboot. We could try to leverage the abuse detection and mitigation mechanisms in the Google services that people are using from their Chromium OS devices, but it seems more scalable to allow each service to continue handling these problems on its own.

Emphasis mine.

Coreboot is a low level OS fully capable of executing code, applications, initiating downloads. The user 'OS', ChromeOS, GNU/Linux, Windows, is a guest OS. Coreboot, UEFI, and company are fully capable of running all hardware on the machine.

https://brmlab.cz/_media/event/coreboot_cisl2012.pdf

Chromium / ChromeOS boot process:

http://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery



Coreboot Etherboot:

http://www.coreboot.org/Etherboot

Boot and install OS from etherboot: http://www.etherboot.org/wiki/appnoted

All the pieces are there in a Chromebook to support Google remotely modifying, bricking, or installing software or firmware. The only visible missing piece is the etherboot module in the coreboot menu. But there's no technical reason to prevent ChromeOS from having the necessary pieces in place. Perhaps, the current crop of Chromebooks are not remote brickable in this way -- but there's no reason to suspect they aren't. And perhaps when Google gets tired of 'developers' installing insecure code and damaging the Chromebook brand image - Google will remotely turn off developer mode until serious developers pay a modest fee. Again, there's no reason to suspect that Google is going to do this at some time in the future - or that they have 'baked' in the necessary components with an eye to future remote recovery... but there's no way to ensure that they haven't -- and, yes, it is possible that they have.

@ljmp:

It's not that a lot of what you're talking about isn't possible. It's just that it's just as possible with other computers. UEFI is actually more of a complete system than Coreboot. Also, using SeaBIOS on a SeaBIOS enabled machine isn't considered a "hack" by Google. It's an option. No actual "hacks" are involved in booting a SeaBIOS enabled Chromebook directly to Linux.

The flowchart you posted doesn't include the SeaBIOS option. It's what happens assuming you're booting to the default firmware for loading ChromeOS. SeaBIOS would be in an alternate choice box right after "Power on." Still, notice that a recovery image in an SD or USB drive is required for actual ChromeOS recovery. Otherwise, assuming you don't have a good installation to boot to, you get stuck in an endless reboot loop until you power off or insert a recovery drive.

Most Chromebooks don't support Etherboot because they have no Ethernet. I don't think that most Chromeboxes support it either, even though they do have Ethernet. However, Etherboot, like similar Ethernet boot methods that have been available on a lot of hardware since the 90's, requires assistance from a DHCP and an FTP server on your local subnet in order to work. I used to use a similar scheme at my workplace to load Windows on computers with no optical drive from 1999 to sometime in the early 2000's, and the hardware I used was at least two years old when I started.

Yes, it's possible in theory to put all sorts of things into the firmware of a device (though network traffic will generally give efforts like this away). If you want to be paranoid, there's no motherboard manufacturer that is safe.

@CFWhitman:

Quoting:The flowchart you posted doesn't include the SeaBIOS option.

Yes it does. SeaBIOS sits in the dark blue "Load Developer Kernel" box near the center of the chart. The chart is not mine, it's directly from the Chromium website as indicated by the link above the chart. The point of the chart is that SeaBIOS is not 'replacing' the coreboot 'stuff', it's being loaded as a plug-in instead of the default plug-in. This is a significant difference. The only reason SeaBIOS is present is to enable 'developers' to load unsigned kernels.

Quoting:It's just that it's just as possible with other computers.

Sure. However, with a Chromebook there is a cryptographically locked permanent backdoor: Google's key placed in non-writable ROM space. Or at least I believe it's non-writable. Although I seem to remember reading somewhere that 'developers' can install their own keys somehow... Also, if I build my own computer from consumer hardware - I can choose particular components which allow me to install my own keys in the optional TPM.

Quoting:though network traffic will generally give efforts like this away

The network traffic can be hidden from the Guest OS, and activated passively through browsing webpages.

CFWhitman wrote:Most Chromebooks don't support Etherboot because they have no Ethernet

http://www.etherboot.org/wiki/wirelessboot

Quoting:Thanks to some work done during Summer of Code 2009, gPXE supports the 802.11 protocol for accessing Wi-Fi wireless networks.

Of course the Summer of Code is the 'Google' Summer of Code.

Again, I'm not saying that Google does, has, is going to xyz whatever... just that it's possible -- and those who claim it's categorically impossible are just plain wrong.

ljmp wrote:Yes it does. SeaBIOS sits in the dark blue "Load Developer Kernel" box near the center of the chart. The chart is not mine, it's directly from the Chromium website as indicated by the link above the chart. The point of the chart is that SeaBIOS is not 'replacing' the coreboot 'stuff', it's being loaded as a plug-in instead of the default plug-in. This is a significant difference. The only reason SeaBIOS is present is to enable 'developers' to load unsigned kernels.

No, it doesn't. I know where the flowchart came from. You cited the source in the post. The flowchart is a flowchart for the Chromium OS firmware only (From the page: "The boot loader is only designed to load Chromium OS. We can go directly from firmware bootstrap to the kernel in the file system."). SeaBIOS is not a "Developer Kernel" it's a different firmware bootstrap. Coreboot hands off either to the Chromium/Chrome OS bootstrap or to SeaBIOS. There is an 'OS verification is turned off' warning screen before it hands off to either the Chrome OS firmware bootstrap or to the SeaBIOS firmware bootstrap. The "Scary Dev Mode screen" referred to here is another warning, something like 'Your computer is not running Chrome OS.' I've never actually seen it on my Chromebook because I've never tried to boot an alternate Chromium OS kernel.

Edit: Just for the sake of completeness the box that reads "Firmware Boot Stub" could cover everything that happens before this flowchart cares about what's happening. That is, it might include Coreboot setting up hardware (and all that entails), followed by a check to see if OS verification is turned on, including a 'no' branch that checks/waits for a decision about whether to go to SeaBIOS or whether to rejoin this branch and check if it should go into recovery. Regardless, the Chromebook firmware decides whether to boot to SeaBIOS before it decides whether to boot to recovery.

Quoting:The network traffic can be hidden from the Guest OS, and activated passively through browsing webpages.

It can theoretically be hidden from the 'guest OS', but it can't be hidden from other machines on the network.

Wireless booting requires a lot of cooperation from the user under the best of circumstances. There are few supported chipsets (which do not appear in any Chromebook I am familiar with, though I'm not familiar with the wireless hardware of nearly every Chromebook out there) and you need to supply information in real time for it to work at all. There is no practical way it could be used reliably for remote boot from the outside.

ljmp wrote:The SeaBIOS 'firmware' is loaded as payload from the coreboot system already running. That statement can be found in coreboot's documentation as well as Google's. The coreboot system is unmodified when the SeaBIOS payload is selected versus the U-Boot payload that would boot the ChromeOS kernel.

This is all true. However, you seem to be proceeding under the impression that the flowchart is a flowchart for Coreboot. That is not the case. The flowchart is only covering what happens after you pick the Chrome/Chromium OS firmware payload (which is now derived from U-boot for all architectures it seems). The documentation included with the flowchart makes this pretty clear if you read it.

The place in the flowchart where it loads either "Firmware A (Setup + Boot Loader)" or "Firmware B (Setup + Boot Loader)" is it actually loading the firmware bootstrap payload, and the whole center section is the payload executing. Everything that happens before the selection of the Chrome OS firmware bootstrap payload either is not included or is covered by that second box called "Firmware Boot Stub." This flowchart is correct whether you are using a model that includes SeaBIOS or not. In fact, I'm not sure that it wouldn't still be correct for a pre-Coreboot Chromebook (that may even be what it was written for) since the only part of the process it covers is the same either way. In fact, the more I think about it, and as I look back through the documentation, the more likely it seems it was written for the pre-Coreboot models (that would explain a lot, including the lack of a mention of Coreboot anywhere in the document). There would be no pressing need to update it since it's still relevant to Coreboot models because it's only covering what happens after Coreboot chooses the Chromium/Chrome OS firmware bootstrap payload.

Edit: At this point, as I look over the whole document, including the way out of date EEPROM map, I'm convinced that this document only covers the pre-Coreboot plans for firmware, and has never received any adjustments related to the change to Coreboot.

Also, if you actually have a Chromebook/Chromebox and are familiar with what happens during boot when you do certain things, you can see the order of what occurs in this flowchart only fits with what happens after the payload for Coreboot is selected.