If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Coreboot Gets Support For Haswell Power Limiting

Phoronix: Coreboot Gets Support For Haswell Power Limiting

After landing hardware support improvements last week for Coreboot, the open-source BIOS firmware replacement now has another new feature: ACPI power limiting and it's been implemented for Intel Haswell CPUs...

All x86 chromebooks run coreboot. There's growing support for (new) ARM chromebooks, but they still ship with pristine u-boot. I guess the ARM support is still too experimental...

Originally Posted by uid313

What sits a top of Coreboot?
It runs TianoCore or SeaBIOS on top of Coreboot, or it boots directly a Linux image?

u-boot. There's also a payload called "depthcharge", that's supposed to implement the same functionality (verified boot etc), that I thought would replace the uboot setup, but I don't know its current status.
The entire setup is designed for a consumer device, not a "PC", hence the lock-down and automated recovery mechanisms.

Newer Chromebooks come with a SeaBIOS option that can be run with a key combination on boot (with scary splash screen to tell you that you're about to leave the ChromeOS environment).

And as usual, Google documents the process to replace their firmware with a plain coreboot firmware (in particular, how to bypass their verified boot mechanism). In that case you get to choose the payload and also don't have to suffer through the scary boot screens. http://johnlewis.ie/ is based on that.

This tells me to get an x86 Chromebook if my netbook is ever destroyed

Originally Posted by pgeorgi

All x86 chromebooks run coreboot.

<snip>

And as usual, Google documents the process to replace their firmware with a plain coreboot firmware (in particular, how to bypass their verified boot mechanism). In that case you get to choose the payload and also don't have to suffer through the scary boot screens. http://johnlewis.ie/ is based on that.

This tells me exactly what to do if I ever have to replace my netbook: get any low-end x86 Chromebook, replace the firmware with straight Coreboot, and replace Chrome OS with my normal encrypted OS (using MATE and IceWM desktop options fopr a light machine). No Microsoft tax, a cheaper machine, total extermination of verfied or delayed boot answering to someone other than myself. Good luck NSA trying to backdoor a machine with no blobs at all...

This tells me exactly what to do if I ever have to replace my netbook: get any low-end x86 Chromebook, replace the firmware with straight Coreboot, and replace Chrome OS with my normal encrypted OS (using MATE and IceWM desktop options fopr a light machine). No Microsoft tax, a cheaper machine, total extermination of verfied or delayed boot answering to someone other than myself. Good luck NSA trying to backdoor a machine with no blobs at all...

The silicon could be backdoored. The compiler used to compile the compiler could be backdoored.
The operating system can have lots of vulnerabilities cleverly disguised as innocent bugs, such as assignment instead of comparison. The implementation of certain cryptographic algorithms could be weakened. See the Underhanded C Contest, the NSA must have whole teams dedicated to that kind of stuff, writing backdoors and introducing vulnerabilities and hiding them in plain sight so even when looking at the source code you won't see anything odd. Then there is zero-day vulnerabilities in the software you use, such as your web browser.

Even assuming your chromebook could be perfectly secure. Your phone, tablet, router, etc wouldn't be and the whole cellular network and Internet network is wiretapped.

I do not own a smartphone or tablet

Originally Posted by uid313

The silicon could be backdoored. The compiler used to compile the compiler could be backdoored.
The operating system can have lots of vulnerabilities cleverly disguised as innocent bugs, such as assignment instead of comparison. The implementation of certain cryptographic algorithms could be weakened. See the Underhanded C Contest, the NSA must have whole teams dedicated to that kind of stuff, writing backdoors and introducing vulnerabilities and hiding them in plain sight so even when looking at the source code you won't see anything odd. Then there is zero-day vulnerabilities in the software you use, such as your web browser.

Even assuming your chromebook could be perfectly secure. Your phone, tablet, router, etc wouldn't be and the whole cellular network and Internet network is wiretapped.

And I do not trust any router or any part of the Internet with sensitive information. I treat all networks as malicious, and know that routers are actualy bigger targets than computers. I do not allow any computer (routers, etc included) to simultaniously handle my encrypted filesystem and connect directly to the Internet. I do not use routers to move sensitive shit between machines, I use encrypted flash drives for that.

I have seen the Underhanded C work, and have read papers concerning hardware backdoors. There have been instances of this being done with computers ordered in advance, then shipped to a known party under surveillance. Embassies and governments are the usual targets-or the usual cases where they get caught. The best defense is to do what I do: buy all components on the spot with cash so nobody can predict which processor, board, etc you will have. The manufacturer cannot predict what examples I will pull from the shelf, and there are no credit card records or Windows activation records to find it after the fact.

Any silicon backdoor must now be in every machine, or in none. Here's the kicker: a always-on backdoor in every machine that talks to the network will be caught by someone running Wireshark for some unrelated reason. Thus, it must be able to be turned on and off. Probably the firmware the device is shipped with-or even its OS-plays a role in that. I never permit any computer I acquire for secure work to talk to any network before the vendor-provided OS has been removed. In this Chromebook case this could be applied as well to the firmware.

Dump both the firmware AND the OS, and turning such a backdoor on becomes much harder, though not totally impossible. That's why the folks handling Snowden's take used randomly purchased, cash-only machines that had never been connected to any network to protect their encrypted data, brought it only by flash drives. I do not now deal with that high a level of secret information, but I do know how it is done.

In the meantime, the NSA will never admit in court to backdooring Intel's or AMD's hardware in open court because Occupy protesters storm a convention of gas fracking CEO's (and local cops or the FBI want the raw video clips), no matter what we do inside. Not worth blowing one or the other chipmaker out of the water trying to solve a less than $1M case.

This tells me exactly what to do if I ever have to replace my netbook: get any low-end x86 Chromebook, replace the firmware with straight Coreboot, and replace Chrome OS with my normal encrypted OS (using MATE and IceWM desktop options fopr a light machine). No Microsoft tax, a cheaper machine, total extermination of verfied or delayed boot answering to someone other than myself. Good luck NSA trying to backdoor a machine with no blobs at all...

Unfortunately it's not quite that simple - the x86 chromebooks are all Intel based. Intel support in coreboot since Sandy Bridge only happened with a binary component to do the RAM initialization. First provided by Google as part of their Chromebook work, but by now Intel is trying to enter that field itself (http://www.intel.com/fsp)

And even if we manage to reverse engineer that (not impossible, but it's tons of work), there's the (by now mandantory) Management Engine with 1.5-5MB of Firmware doing who-knows-what, with access to all critical parts of the system.
Its firmware is apparently signed with an Intel key, so we couldn't replace it, no matter how much time we spend on it, except maybe by exploiting bugs in its firmware, which really isn't a very sane way to work with chipsets... As for bugs in ME firmware (or silicon), see https://events.ccc.de/congress/2013/...ents/5380.html. I guess the talk will be streamed and also made available for download after the event (as is typical for the congress).

The situation on AMD isn't quite as dire, but they have some binary components, too. The fortunate thing is that their binary modules are much smaller, apparently unsigned, and the chips they run are much more limited in what they can do to the system. So it's possible to analyze them or write a replacement (one of the coreboot developers built a prototype replacement for one of them).
Unfortunately there's no AMD chromebook (but that might change: http://www.coreboot.org/pipermail/co...er/076656.html)

As for the ARM chromebooks (and ARM devices in general), they often ship with a chip-vendor signed initial bootloader. It's typically very small, so a full audit might be realistic.

So from that point of view, an ARM device with mostly-available source code (ie. everything but that initial bootloader) is probably your best bet when it comes to security.
It also helps (from a bugged-silicon point of view) that there are so many different ARM vendors - some of them do their own CPUs and merely license the ISA, so it isn't enough to bug ARM Ltd. and their reference designs, while it's probably impossible to bug all their licensees (but then we're talking nation state actors here ;-) ).

The best defense is to do what I do: buy all components on the spot with cash so nobody can predict which processor, board, etc you will have. The manufacturer cannot predict what examples I will pull from the shelf, and there are no credit card records or Windows activation records to find it after the fact.

This doesn't save you if all motherboards, chipsets, or processors are backdoored.
Then any component you get handed will be backdoored regardless if your identity is known.

No, the Chinese fear that American Cisco routers are backdoored.
Meanwhile, the Americans fear that Chinese Huawei routers and network equipment is backdoored.
Of course that doesn't remove the possibility that both or none of them are backdoored.

Originally Posted by Luke

Here's the kicker: a always-on backdoor in every machine that talks to the network will be caught by someone running Wireshark for some unrelated reason.

Unless it wasn't designed for remote usage. It could be used for local privilege escalation, etc.

Originally Posted by Luke

Thus, it must be able to be turned on and off. Probably the firmware the device is shipped with-or even its OS-plays a role in that.

The backdoor could be in the CPU microcode or the silicon, then it wouldn't need any firmware or binary blobs.

No, the Chinese fear that American Cisco routers are backdoored.
Meanwhile, the Americans fear that Chinese Huawei routers and network equipment is backdoored.
Of course that doesn't remove the possibility that both or none of them are backdoored.

Unless it wasn't designed for remote usage. It could be used for local privilege escalation, etc.

The backdoor could be in the CPU microcode or the silicon, then it wouldn't need any firmware or binary blobs.

1: No machine with vPro or similar out-of-band management can be trusted or used for secure information, this has been known for years.
It is also known that vPro can be broken so far as remote attack is concerned by connecting to the network with a discrete non-Intel
network card and not using the one vPro depends on at all. Still not trusted as it could store something locall for a later raid once
triggered.

2: Local attacks: If a machine is not secured against local physical access, it cannot be considered secure for encrypted material. Thus,
a local privilige escalation attack would be against a machine considered already compromised. Any evidence that a machine has
been powered up by an unknown party requires DISPOSAL of a machine handling high value encrypted files anyway.

3: The best evidence that hardware backdoors are not storing encryption passphrases or keys locally is that nobody in any protest movement,
direct action political movement, armed group, or organized crime ring has been arrested based on the take from a hardware backdoor
decrypting an encrypted computer-anywhere.

4: Putting the backdoor itself in the silicon is not enough. For the attack I am concerned with, it would need to predict what encryption
program would be used, where they key would go in RAM, that kind of stuff, even on encryption programs yet to be written or updated.
Pretty soon you are asking to add a lot of gates for "hardware-accelerated policing." The more undocumented gates, the greater the risk
of detection or just plain suspicion after someone X-rays the chip.

Security is always a balancing act, and always an arms race. So is attacking. Secure today may not be secure tomorrow, but you pick all low-hangng fruit, every time. When more is needed, such as at the Snowden level, a far more detailed study is needed-and if something does not NEED to be on computer, it should not be at that point. Strong defenses are layered-get through one and face another, like cracking a DM-crypt disk after a month of supercomputer time, only to find a Truecrypt container using a different cypher, key, and passphrase staring back at you. Maybe you crack that passphrase too, getting lucky on the first round of dictionary attacks, only to find those raw video clips you wanted were all shredded with random numbers instead of being saved. You'd have to be awful determined not to throw in the towel at that point.

Encryption… AES-NI?

Hello!

I just found the Phoronix article about the Asus Chromebook C720 and thought to myself that this netbook might be the ideal replacement for my old Asus EeePC 901 netbook. So I checked it out and found that it uses an Intel Celeron 2955U processor. This particular CPU lacks AES-NI support. But especially for netbooks with ULV and LV processors (which in general are not very fast) AES hardware instructions would be very helpful to keep good overall performance when using encrypted partitions.

So, I refrain from this idea to get the Asus Chromebook.

I am still looking for a netboot that meets the following criteria:

Architecture: x86 i.e. IA-32

Firmware: Coreboot, but with the possibility to add SeaBIOS or Tiano Core for Windows compatibility

OS: Arch Linux or Debian GNU/Linux, but using LUKS to encrypt everything. Windows is planned only as a second OS if at all, but then unencrypted.