Why is the latest AMD hardware unsupported in libreboot? | Hacker News Reader

Why is the latest AMD hardware unsupported in libreboot?

libreboot.org

85 pointsrnhmjoj60 comments

To be fair, see: https://libreboot.org/faq/#intel

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?

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.

Or we could keep pressuring AMD and Intel to open up that proprietary code.

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.

it's time for: http://www.lowrisc.org/

For desktops, it simply needs to get into the fast enough territory.

They don't even do microcode updates, which is ridiculous when you are running non-free microcode to boot.

Is it Libreboot who is being ridiculous, or Intel/AMD? Is it worth trusting OEMs with wholesale access to your data and your networks?

Is never-updated proprietary microcode somehow better than updated proprietary microcode?

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.

That's a false dichotomy.

It isn't in this case.

So if Intel discovers a bug in their chip that needs to be patched with a microcode update then Libreboot users are just SOL? That can't be right.

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.

Yes, see this libreboot-supported laptop as an example: https://libreboot.org/docs/hcl/x200.html

  The X200, when run without CPU microcode updates in coreboot,
  currently kernel panics if running QEMU with vt-x enabled on 2 cores for the guest.

Oops.

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.

Fun quote from http://www.gnu.org/philosophy/free-hardware-designs.en.html for example:

"Any program in your computer, that someone else is allowed to change but you're not, is an instrument of unjust power over you"

And they don't list any Nvidia hardware at all here, as far as I can tell:

https://libreboot.org/docs/hcl/index.html

So I guess their solution is to hoard 2013-vintage hardware for the rest of all time?

Only one desktop motherboard is supported. Can you even find them anymore? Only 5 listed globally on eBay.

Actually, if you click through, that desktop motherboard isn't even supported in the 20150518 release :-/

Whole page is an enlightening read, with quite a few disappointing discoveries, such as:

  There are several privacy, security and freedom issues
  with [Purism Librem laptops], due to the Intel chipset

They're probably talking about the wireless network adapter here, not the CPU. If that's what you're implying.

Alas, CPU. Namely ME[1] and FSP/SMM blob [2].

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

tl;dr: It's not just AMD, it's anything AMD after 2013 and anything Intel after 2009. So essentially all modern x86 hardware.

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

(disclaimer: I'm working at VIA)

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.

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 would be best implemented on a secure platform, so having something "anybody" can get their hands on, rather than only playing ball within the military space, might work out more profitably.

Besides contracts, whoever does this will inevitably get a LOT of publicity from the open source movement, so they'll need to have a good department to handle that, along with the sometimes OCD-to-the-point-of-being-awkward stance that GNU takes sometimes.

There are other issues, such as running the system off entirely free-software drivers; I'm not sure where VIA's at on that front, but that would be an arguably necessary part of such a platform as this (the argument against this type of thing being that if there are Components(TM) in the hardware that can do fun tricks, said Components(TM) need to be communicated with, and that might be happening in the drivers.)

And I'd finally get to build the secure communications device I've always wanted to make. :D

(Incidentally, current smartphones are a security nightmare: https://www.devever.net/~hl/nosecuresmartphone is as non-theoretical as it gets without providing PoC explots, IMO).

[PS. Honestly not trying to big-note myself or anything - I'm just a tinkerer/hobbyist - but feel free to copy/forward this text.]

I wonder if you get better performance per watt on 2012 AMD chips or 2008 Intel chips

Most likely not. Perf/watt was one of the aspects both Intel and AMD were focusing on since then.

I am guessing that was meant to be a comparison between those two old chips, not a comparison between those older chips and modern ones.

And ARM

On ARM side, RK3288* looks promising:

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

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.

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.

remember that ARM is not a manufacturer. Samsung and the likes churn out the current ARM chips.

And i trust Samsung with security even less than AMD or Intel.

It could die off if we discover the NSA stole Intel/AMD's keys to backdoor every computer in existence.

"ARM is probably the closest open chip platform out there"

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.

I meant that it's a spec, my point wasn't perfect, but there really aren't OpenSource chips.

Yet another battle in the War On General Purpose Computers is lost.

From the Intel section ( https://libreboot.org/faq/#intelme )

> 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?

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.

I didn't say the hardware wasn't useful anymore.

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.

I think I'd rather have a machine that has a verified chain of trust from boot than one that will happily run anything.

I prefer secure boot without backdoors.

http://www.tianocore.org/

That has non-free code to read the FAT partition.

It also really needs a security audit.

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.

There’s usually a jumper you can set on the motherboard that controls whether you can reflash firmware. So you can burn Coreboot and set it back.

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.

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"?

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.

> 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!

> Allowing Secure Boot to be bypassed is a backdoor in itself.

Like Ubuntu does?

http://firmwaresecurity.com/2016/01/07/ubuntus-uefi-secure-b...

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.

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.

> though I'm unclear on where the coreboot/libreboot line lies

afaik libreboot is "just" deblobbed coreboot

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

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.

Reply on news.ycombinator.com