I was wondering this myself. I was wondering why they were focusing so much on AMD when all AMD did was copy Intel's horrible idea.
It seems kind of pointless to continue the Libreboot project if they're not going to work on any modern hardware for the foreseeable future. Their recommended systems are all old and out of production. Fastest recommended laptop seems to be roughly a Core2Duo at 2.0Ghz.
Well that's the good old GNU/FSF firmware reasoning; its "better" to have the same firmware permanently burned into a chip than have it software upgradeable. Also happens to be one of the reasons I think FSF has lost its way if they ever even had it in the first place.
In a significant sense it is. It means if it wasn't malicious from the factory then it can't be malicious now.
The best security design for software-in-hardware always starts with the software being burned into ROM. Then you can pick from one of two ways to do updates.
The first is the updates are received from the operating system during every boot, so removing power is a reset to factory. So if you throw the system disk in the trash and replace it with a clean one you know you have a clean system. This is in nearly every sense the best way to do it, except that you can't fix a firmware bug that exhibits before the OS boots.
The second is to have some flash memory on the hardware that can be used to install firmware updates, but have a jumper that determines if the system will look there or in ROM during boot. Then if you want clean updated firmware you set the jumper to ROM, boot and install the clean firmware to the flash and then set it back the other way.
The best solution is to support both and then ship the system with the jumper set to ROM. Then you can do 99% of updates automatically through the OS and in the event of a pre-boot firmware bug the affected user can still install the update manually if necessary.
Linux supports applying microcode updates as part of the kernel boot process, so you are not dependent on the motherboard firmware to do it and you still get the microcode loaded pretty early.
They don't work on mainstream PC platforms, but for embedded use Coreboot/Libreboot has a much better story. For example, Atom and Geode systems support it basically by default, and many boards ship with it preinstalled.
I am both amazed and terrified. I'm amazed that we're in an age where the processor I'm using to do all the things I do has it's own processor that's running it's own OS, has a Webserver and running a Java stack. I'm also terrified about what this processor could do at any moment. Is there away to inspect the IME bytecode to see if they put any backdoors in there? How is this code updated?
The bug was in the RK808 PMIC, which may or may not be used on an RK3288 based system. It looks like the RK3288-based ChromeOS devices do use it though.
I wonder if VIA hardware could be supported. There are modern CPUs/motherboards coming out there, and even if they are on a different performance level (being embedded-focused hardware), in 2016 they must beat Intel-from-2009 and should get close to AMD-from-2013...
It would be interesting to throw this URL as far up the internal chain as possible... and see what happens. :P
I'm curious myself, and there are a lot of other people who wouldn't mind knowing too. Fast AND trustworthy turnkey silicon is both a completely untapped hole in tech at the moment and something that's desperately needed in this climate of NDA'd garbage-quality security systems (see https://www.devever.net/~hl/smartcards for one of thousands of examples) and increasingly locked down chipsets.
On the other hand, x86 is a widely (!) used, well-known ISA with a lot of legacy software running on it, and VIA already have proven CPUs and chipsets and motherboards. I only know about VIA as "the low-power alternative CPU company," so I have no idea what it's position or stance on secure applications is, but it could well net itself some unique contracts by investing in security.
One of the big problems in this space (or at least what's being made into a problem by the major chip vendors) is secure bootstrapping: I can verify the entire boot device (a 128MB boot image could read in a second or two from eMMC)... but how do I know that "I", aka the code doing the verification, have not been compromised? It's a chicken-and-egg problem.
Here's my back-of-an-envelope approach: create a CPU with a secure, write-once, write-only (executable) PROM of say 64KB (maybe 256KB? 512KB?), and ship the chips with this area blank. The customer writes whatever data they like to that area of the chip, and then the chip begins execution (ie, PC = 0, or close to it) running whatever code it finds there. Maybe you'd call this the "pre-BIOS area".
You could write a public key and a verification routine in there and use it to verify everything else the system wanted to load. Besides verifying the BIOS, which would be nice, you could verify the boot media..... bam. Trustworthy boot sequence.
This might be surprising to hear, but right now, the above is a pipe dream. It's 2016, and yet, even something as basic as this does not exist - if anything, we're moving away from such a position with the current state of things. The above cannot be done with any hardware/ISA/chipset I'm aware of. For example, the Raspberry Pi Zero (the latest one) still uses the proprietary ARM core in the GPU to handle bootup (http://raspberrypi.stackexchange.com/questions/38585/raspber...), which is basically the opposite of what I've just described here.
Whoever says "I can do this!" is going to get some interesting offers. The military can of course afford to design/get whatever they want, and fat contracts from them are always fun... but think of all the private companies that would benefit from guaranteeably secure data acquisition and/or communication... that's everything from the stock market to secure money courier vans. All that industry, taken together, amounts to a lot of (untapped!) potential. What's more, the private sector is always going to come up with ideas that ...
Given that AMD and Intel are both driven by large for profit customers and their requirements, these concerns will probably only get worse.
ARM is probably the closest open chip platform out there, but even that is not Free in the FSF sense or $ sense. It seems that the project is going to forgo user-base for principles, and then most likely no longer be relevant.
It's great to try and fight for and defend your principles, but if that means that you no longer have a user base on which to stand, then the fight will be of little value. I'd love to be wrong about this, but I can't logically see another way that this will play out.
I guess the better question would be why they're even bothering any more when they only support a few ancient Thinkpads and a couple of decade old Apple laptops.
For better or worse, I think they've lost this battle.
I'm still using one of these "ancient" Thinkpads (an X200S). It's good enough for my purposes (audio recording, live audio performances, hacking on free software, Emacs, browsing the web).
I don't often find myself wishing for a more powerful machine. When I do, I run computations on remote servers.
But it seems like a losing proposition to run and promote a project that's only ever going to run on a handful of ancient laptops. The FAQ explicitly says it's not going to run on any new Intel or AMD processors, which essentially makes it useless for modern desktop, laptop, and server systems. As others have pointed out, it's almost not even possible to buy hardware that's supported.
Yup. You don't get software freedom if not only you but everyone else also has the freedom to control what your machine runs. Giving everyone control of your machine is as much of a non-solution as giving only your hardware manufacturer control of your machine; it's simply that one is a better short-term compromise.
> everyone else also has the freedom to control what your machine runs.
> Giving everyone control of your machine
like... [citation needed]
Coreboot giving everyone access? The entire point of the project is so you know and can verify there’s no backdoor to your CPU. How do you turn it around 180°…? This is so dishonest.
You can ensure there's no backdoor in the machine as shipped from the manufacturer. That's extremely important and a good thing to have, and I'm not disputing that.
What you'd like to do is make sure that there are no further backdoors, via bootkits, evil maid attacks, whatever. If I can reflash the firmware or insert myself into the boot process, who else can?
If you cannot reflash the firmware or insert yourself into the boot process, who else still can?
Just because your hardware prevents you from inspecting and modifying it, doesn't mean it prevents everyone else from doing so. Very much the opposite. If you can't inspect it, chances are it does allow others to use your hardware against you.
How many people are qualified to "verify there's no backdoor to your CPU"? Certainly not your average user. If you can't trust your CPU, what can you trust?
Allowing Secure Boot to be bypassed is a backdoor in itself. Allowing the end-user to modify the firmware at all also allows malicious actors to do the same.
> How many people are qualified to "verify there's no backdoor to your CPU"? Certainly not your average user.
I meant there are no backdoors in firmware. Some poor phrasing on my part, sorry. Backdoors in CPUs are obviously a completely different issue altogether.
> Allowing Secure Boot to be bypassed is a backdoor in itself.
You can have open source implementation of Secure Boot as a Coreboot payload. One such implementation is Tiano Core (UEFI).
> Allowing the end-user to modify the firmware at all also allows malicious actors to do the same.
Modifying firmware to flash Coreboot usually involves at least switching jumpers or actually physically flashing the memory chip.
But even if there’s no hardware switch you are still free to implement whatever security you like in the firmware. Because you control the firmware. So if you want to have signed payloads that’s just fine!
> How many people are qualified to "verify there's no backdoor to your CPU"?
More than the manufacturer, if it's open, and that's the point.
The manufacturer has an interest or can be pressured into having an interest in keeping backdoors secret. The point is not that every user will themselves audit the firmware, the point is that everyone in principle could either learn to do it themselves or hire someone with the neccessary knowledge to do the audit for them.
Food safety also isn't achieved by having everyone test their food in their own labs, but by anyone being able to hire a lab of their choice to do tests they want to have done.
> Allowing the end-user to modify the firmware at all also allows malicious actors to do the same.
And allowing the end-user to swap out the lock to their house also allows malicious actors to do the same?
Just because you can swap out a flash chip on your mainboard, doesn't mean anyone can come into your house and do the same.
They promote freedom but specifically forbid the use of Windows. Not everyone has the choice to not use Windows at certain points in the day, VMs aren't perfect. Forbidding the bare-metal usage of Windows is ridiculous.
I mean, they're promoting the freedom to use a bunch of 2006–2009-era ThinkPads and MacBooks, and if you use the git release, a couple of motherboards from the same time period and maybe one 2015 Chromebook if you're lucky.
I appreciate that this work is being done (though I'm unclear on where the coreboot/libreboot line lies, but anyway), but calling it "freedom" is a stretch. It very much feels like the freedom to move to an abandoned island and not pay taxes or be subject to any government.
> It very much feels like the freedom to move to an abandoned island and not pay taxes or be subject to any government.
Except, unless I'm mistaken, US citizens don't even have that freedom. Unless you renounce your citizenship, you pay US taxes wherever you live, unless there's a tax treaty of some kind in place between the US and your country of residence.
> It very much feels like the freedom to move to an abandoned island and not pay taxes or be subject to any government.
It might be a stretch to be able to use Coreboot for work or entertainment at the moment, unfortunately. But consider that those specs are just fine for most privacy sensitive stuff. Tor, email, banking… etc.
So for a separate, trusted, privacy-focused box a few years old, slightly slower CPU is not a big deal. And you get the compartmentalization for free!
Windows is just unsupported. It’s not “forbidden.” Coreboot has SeaBIOS and UEFI implementation as payloads that are os-independent. So Windows might work. Or not.
You shouldn’t want to run Windows on a privacy sensitive workstation though. Compartmentalization and all that.
> If the manifest isn't signed by a specific Intel key, the boot ROM won't load and execute the firmware and the ME processor core will be halted.
So if I just overwrite a few bytes of flash on my motherboard (i.e. corrupt the signature), the whole thing is disabled? It says the _ME_ core is halted. But the main CPU continues to run? Are there side effects? Why is this not a solution?
Also: is there more (probably community reverse-engineered) documentation on the ME's specifics?
63 comments
[ 2.9 ms ] story [ 135 ms ] threadhttps://libreboot.org/docs/hcl/index.html
So I guess their solution is to hoard 2013-vintage hardware for the rest of all time?
It seems kind of pointless to continue the Libreboot project if they're not going to work on any modern hardware for the foreseeable future. Their recommended systems are all old and out of production. Fastest recommended laptop seems to be roughly a Core2Duo at 2.0Ghz.
"Any program in your computer, that someone else is allowed to change but you're not, is an instrument of unjust power over you"
The best security design for software-in-hardware always starts with the software being burned into ROM. Then you can pick from one of two ways to do updates.
The first is the updates are received from the operating system during every boot, so removing power is a reset to factory. So if you throw the system disk in the trash and replace it with a clean one you know you have a clean system. This is in nearly every sense the best way to do it, except that you can't fix a firmware bug that exhibits before the OS boots.
The second is to have some flash memory on the hardware that can be used to install firmware updates, but have a jumper that determines if the system will look there or in ROM during boot. Then if you want clean updated firmware you set the jumper to ROM, boot and install the clean firmware to the flash and then set it back the other way.
The best solution is to support both and then ship the system with the jumper set to ROM. Then you can do 99% of updates automatically through the OS and in the event of a pre-boot firmware bug the affected user can still install the update manually if necessary.
For desktops, it simply needs to get into the fast enough territory.
If you are wondering what's wrong with either of them, I would recommend Joanna Rutkowska's research as a starting point [3,4].
[1] https://libreboot.org/faq/#intelme
[2] https://libreboot.org/faq/#fsp
[3] http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
[4] https://media.ccc.de/v/32c3-7352-towards_reasonably_trustwor...
https://libreboot.org/docs/hcl/c201.html
* Yes, that is the very same RK3288 that has an embarrassing calendar bug discussed here a month ago: https://news.ycombinator.com/item?id=10768140
(disclaimer: I'm working at VIA)
I'm curious myself, and there are a lot of other people who wouldn't mind knowing too. Fast AND trustworthy turnkey silicon is both a completely untapped hole in tech at the moment and something that's desperately needed in this climate of NDA'd garbage-quality security systems (see https://www.devever.net/~hl/smartcards for one of thousands of examples) and increasingly locked down chipsets.
I'm not sure what else is out there, but I recently learned of RISC-V (http://www.adapteva.com/andreas-blog/why-i-will-be-using-the... ); I'll admit I was impressed to learn a free (open design) CPU has just broken the GHz barrier (http://riscv.org/download.html#tab_rocket_core), but this chip and ISA are still in the early prototyping stages, although the spec seems complete.
On the other hand, x86 is a widely (!) used, well-known ISA with a lot of legacy software running on it, and VIA already have proven CPUs and chipsets and motherboards. I only know about VIA as "the low-power alternative CPU company," so I have no idea what it's position or stance on secure applications is, but it could well net itself some unique contracts by investing in security.
One of the big problems in this space (or at least what's being made into a problem by the major chip vendors) is secure bootstrapping: I can verify the entire boot device (a 128MB boot image could read in a second or two from eMMC)... but how do I know that "I", aka the code doing the verification, have not been compromised? It's a chicken-and-egg problem.
Here's my back-of-an-envelope approach: create a CPU with a secure, write-once, write-only (executable) PROM of say 64KB (maybe 256KB? 512KB?), and ship the chips with this area blank. The customer writes whatever data they like to that area of the chip, and then the chip begins execution (ie, PC = 0, or close to it) running whatever code it finds there. Maybe you'd call this the "pre-BIOS area".
You could write a public key and a verification routine in there and use it to verify everything else the system wanted to load. Besides verifying the BIOS, which would be nice, you could verify the boot media..... bam. Trustworthy boot sequence.
This might be surprising to hear, but right now, the above is a pipe dream. It's 2016, and yet, even something as basic as this does not exist - if anything, we're moving away from such a position with the current state of things. The above cannot be done with any hardware/ISA/chipset I'm aware of. For example, the Raspberry Pi Zero (the latest one) still uses the proprietary ARM core in the GPU to handle bootup (http://raspberrypi.stackexchange.com/questions/38585/raspber...), which is basically the opposite of what I've just described here.
Whoever says "I can do this!" is going to get some interesting offers. The military can of course afford to design/get whatever they want, and fat contracts from them are always fun... but think of all the private companies that would benefit from guaranteeably secure data acquisition and/or communication... that's everything from the stock market to secure money courier vans. All that industry, taken together, amounts to a lot of (untapped!) potential. What's more, the private sector is always going to come up with ideas that ...
ARM is probably the closest open chip platform out there, but even that is not Free in the FSF sense or $ sense. It seems that the project is going to forgo user-base for principles, and then most likely no longer be relevant.
It's great to try and fight for and defend your principles, but if that means that you no longer have a user base on which to stand, then the fight will be of little value. I'd love to be wrong about this, but I can't logically see another way that this will play out.
And i trust Samsung with security even less than AMD or Intel.
I don't know what you think is open about ARM. AMD even uses the ARM locking-down technology to implement its system management processor.
For better or worse, I think they've lost this battle.
I don't often find myself wishing for a more powerful machine. When I do, I run computations on remote servers.
But it seems like a losing proposition to run and promote a project that's only ever going to run on a handful of ancient laptops. The FAQ explicitly says it's not going to run on any new Intel or AMD processors, which essentially makes it useless for modern desktop, laptop, and server systems. As others have pointed out, it's almost not even possible to buy hardware that's supported.
> Giving everyone control of your machine
like... [citation needed]
Coreboot giving everyone access? The entire point of the project is so you know and can verify there’s no backdoor to your CPU. How do you turn it around 180°…? This is so dishonest.
What you'd like to do is make sure that there are no further backdoors, via bootkits, evil maid attacks, whatever. If I can reflash the firmware or insert myself into the boot process, who else can?
Also if someone can flash your firmware your security (on the software or physical access side) is already busted and it’s game over anyway.
Just because your hardware prevents you from inspecting and modifying it, doesn't mean it prevents everyone else from doing so. Very much the opposite. If you can't inspect it, chances are it does allow others to use your hardware against you.
Allowing Secure Boot to be bypassed is a backdoor in itself. Allowing the end-user to modify the firmware at all also allows malicious actors to do the same.
I meant there are no backdoors in firmware. Some poor phrasing on my part, sorry. Backdoors in CPUs are obviously a completely different issue altogether.
> Allowing Secure Boot to be bypassed is a backdoor in itself.
You can have open source implementation of Secure Boot as a Coreboot payload. One such implementation is Tiano Core (UEFI).
> Allowing the end-user to modify the firmware at all also allows malicious actors to do the same.
Modifying firmware to flash Coreboot usually involves at least switching jumpers or actually physically flashing the memory chip.
But even if there’s no hardware switch you are still free to implement whatever security you like in the firmware. Because you control the firmware. So if you want to have signed payloads that’s just fine!
More than the manufacturer, if it's open, and that's the point.
The manufacturer has an interest or can be pressured into having an interest in keeping backdoors secret. The point is not that every user will themselves audit the firmware, the point is that everyone in principle could either learn to do it themselves or hire someone with the neccessary knowledge to do the audit for them.
Food safety also isn't achieved by having everyone test their food in their own labs, but by anyone being able to hire a lab of their choice to do tests they want to have done.
> Allowing the end-user to modify the firmware at all also allows malicious actors to do the same.
And allowing the end-user to swap out the lock to their house also allows malicious actors to do the same?
Just because you can swap out a flash chip on your mainboard, doesn't mean anyone can come into your house and do the same.
Like Ubuntu does?
http://firmwaresecurity.com/2016/01/07/ubuntus-uefi-secure-b...
http://www.tianocore.org/
It also really needs a security audit.
I appreciate that this work is being done (though I'm unclear on where the coreboot/libreboot line lies, but anyway), but calling it "freedom" is a stretch. It very much feels like the freedom to move to an abandoned island and not pay taxes or be subject to any government.
Except, unless I'm mistaken, US citizens don't even have that freedom. Unless you renounce your citizenship, you pay US taxes wherever you live, unless there's a tax treaty of some kind in place between the US and your country of residence.
afaik libreboot is "just" deblobbed coreboot
It might be a stretch to be able to use Coreboot for work or entertainment at the moment, unfortunately. But consider that those specs are just fine for most privacy sensitive stuff. Tor, email, banking… etc.
So for a separate, trusted, privacy-focused box a few years old, slightly slower CPU is not a big deal. And you get the compartmentalization for free!
That’s my perspective, at least.
You shouldn’t want to run Windows on a privacy sensitive workstation though. Compartmentalization and all that.
> If the manifest isn't signed by a specific Intel key, the boot ROM won't load and execute the firmware and the ME processor core will be halted.
So if I just overwrite a few bytes of flash on my motherboard (i.e. corrupt the signature), the whole thing is disabled? It says the _ME_ core is halted. But the main CPU continues to run? Are there side effects? Why is this not a solution?
Also: is there more (probably community reverse-engineered) documentation on the ME's specifics?