Results 1 to 10 of 14

Thread: Coreboot Gets Support For Haswell Power Limiting

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,829

    Default 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...

    http://www.phoronix.com/vr.php?view=MTUzNzY

  2. #2
    Join Date
    Dec 2011
    Posts
    2,053

    Default

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

    It's too bad Coreboot is just on a few embedded devices, I would love to have open source firmware on my desktop, laptop, tablet, and phone.

  3. #3
    Join Date
    Jan 2013
    Posts
    24

    Default

    Quote Originally Posted by uid313 View Post
    Does all Chromebooks run Coreboot?
    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...

    Quote Originally Posted by uid313 View Post
    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.

  4. #4
    Join Date
    May 2013
    Posts
    538

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

    Quote Originally Posted by pgeorgi View Post
    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...

  5. #5
    Join Date
    Dec 2011
    Posts
    2,053

    Default

    Quote Originally Posted by Luke View Post
    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.

  6. #6
    Join Date
    May 2013
    Posts
    538

    Default I do not own a smartphone or tablet

    Quote Originally Posted by uid313 View Post
    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.

  7. #7
    Join Date
    Jan 2013
    Posts
    24

    Default

    Quote Originally Posted by Luke View Post
    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 ;-) ).

    If it has to be x86 compatible, I'd propose AMD.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •