Live data from Hacker News

Why is the latest AMD hardware unsupported in libreboot?

libreboot.org

41–50 of 64 posts

Re: Why is the latest AMD hardware unsupported in libreboot?

#41
post #34
post #25

Earlier quoted context omitted.

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.

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.

Re: Why is the latest AMD hardware unsupported in libreboot?

#42
post #18

Earlier quoted context omitted.

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.

Re: Why is the latest AMD hardware unsupported in libreboot?

#43
post #7

Earlier quoted context omitted.

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

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.

Re: Why is the latest AMD hardware unsupported in libreboot?

#44
post #7

Earlier quoted context omitted.

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

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.

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.

Re: Why is the latest AMD hardware unsupported in libreboot?

#45
post #34

Earlier quoted context omitted.

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

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!

Re: Why is the latest AMD hardware unsupported in libreboot?

#48
post #34

Earlier quoted context omitted.

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

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.

Re: Why is the latest AMD hardware unsupported in libreboot?

#49
post #29
post #26

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…

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

Re: Why is the latest AMD hardware unsupported in libreboot?

#50
post #36
post #34

Earlier quoted context omitted.

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

Post reply on HN