[mjg59]

What? You can build an entirely free UEFI. ACPI has a free compiler and a free interpreter. Neither implies or requires the existence of non-free blobs, and neither implies or requires any code running in a more privileged environment than the OS.

[pabs3]

Which x86 devices ship with a free UEFI/ACPI? Or even allow users to replace the preinstalled UEFI/ACPI with a free one?

[mjg59]

I've a bunch of devices running coreboot with a Tianocore payload, but they're largely either very weird and now unavailable or I haven't upstreamed them so it's not super helpful, but it's absolutely not impossible and you can certainly buy Librebooted devices

[yjftsjthsd-h]

> Which x86 devices ship with a free UEFI/ACPI?

https://doc.coreboot.org/distributions.html seems to say Purism, Star Labs, and System76

(Edit: actually weirdly enough Librem seems to be using a different coreboot payload instead of edk2, but the other 2 stand)

> Or even allow users to replace the preinstalled UEFI/ACPI with a free one?

So many Chromebooks: https://docs.mrchromebox.tech/docs/supported-devices.html

[M95D]

Let's say some hw manufacturer would open-source the required specs to implement it on it's chips. (Very unlikely, but let's say they do...) So what? Dangerous capabilites remain.

[mjg59]

What do you mean by "Dangerous capabilities"?

[M95D]

https://en.wikipedia.org/wiki/UEFI#Criticism

https://en.wikipedia.org/wiki/ACPI#Criticism

https://en.wikipedia.org/wiki/System_Management_Mode#Problem...

[mjg59]

Could you please describe the meaningful difference between SMM and Trustzone, or why the properties of UEFI and ACPI are dangerous?

[M95D]

Until UEFI and secure boot, SMM would run code provided by the BIOS. BIOS was updatable, moddable, replaceable. See coreboot and numerous BIOS mods such as wifi whitelist removal.

Trustzone usually runs code from eMMC. These chips are programed in factory with a secret key in the RPMB partiton. It's a one-time operation - the user can't replace it. Without that key you can't update the code Trustzone executes. Only the manufacturer can update it.

Also, any ring -2 code can be used for secure boot locking the device to manufacturer approved OS, enforce DRM, lock hardware upgrades and repairs, spy, call home, install trojans by remote commands, you name it. And you can't audit what it does.

[mjg59]

You've managed to reference multiple concepts in a way that misrepesents basically all of them, well done.

[mjg59]

To respond in more detail: secure boot (as in the UEFI specification) does nothing to prevent a user from modifying their system firmware. Intel's Boot Guard and AMD's Platform Secure Boot do, to varying degrees of effectiveness, but they're not part of the UEFI spec and are not UEFI specific. I have replaced UEFI firmware on several systems with Coreboot (including having ported Coreboot to that hardware myself), I am extremely familiar with what's possible here.

> Trustzone usually runs code from eMMC.

This might be true in so far as the largest number of systems using Trustzone may be using eMMC, but there's nothing magical about eMMC here (my phone, which absolutely uses Trustzone, has no eMMC). But when you then go on to say:

> Without that key you can't update the code Trustzone executes. Only the manufacturer can update it.

you're describing the same sort of limitation that you decried with SMM. As commonly deployed, Trustzone is strictly worse for user freedom than SMM is. This isn't an advantage for Arm.

> Also, any ring -2 code can be used for secure boot locking the device to manufacturer approved OS

No, the secure boot code that implements cryptographic validation of the OS is typically running in an entirely normal CPU mode.

> enforce DRM

This is more typical, but only on Arm - on x86 it's typically running on the GPU in a more convoluted way.

> lock hardware upgrades and repairs

Typically no, because there's no need at all to do any sort of hardware binding at that level - you can implement it more easily in normal code, why make it harder?

> spy

When you're saying "can be used", what do you mean here? Code running in any execution environment is able to spy.

> call home

Code in SMM or Trustzone? That isn't literally impossible but it would be far from trivial, and I don't think we've seen examples of it that don't also involve OS-level components.

> install trojans by remote commands

Again, without OS support, I'm calling absolute bullshit on this. You're going to have an SMM trap on every network packet to check whether it's a remote command? You're going to understand a journaling filesystem and modify it in a way that remains consistent with whatever's in cache? This would be an absolute nightmare to implement in a reliable way.

> And you can't audit what it does.

Trustzone blobs do have a nasty habit of being encrypted, but SMM is just… sitting there. You can pull it out of your firmware. It's plain x86, an extremely well understood architecture with amazing reverse engineering tools. You can absolutely audit it, and in many ways it's easier to notice backdoors in binary than it is in source.

Trustzone is mostly deployed on Devicetree-based platform. What saves you here isn't the choice of firmware interface, it's whether the platform depends on hostile code. If you don't care about secure boot (or if you do but don't care about updating the validation keys at runtime), you can implement a functional UEFI/ACPI platform on x86 with zero SMM.