[M95D]

Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it?

Device tree does the same thing and it's open source. Even if you only extract it in binary form a proprietary kernel or uboot, you can decompile it very easily.

[yjftsjthsd-h]

> Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it?

Well, no, UEFI can have proprietary implementations, but nothing prevents just shipping edk2.

Conversely, there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring 0. You're kinda pointing out a real problem, but confusing it with a different part of the stack.

[M95D]

> there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring 0

It's not the same!

A bootloader, once it loads the kernel and executes it, is overwritten in memory. No trace of it remains while the sistem is running - until the next boot. UEFI / ACPI / SMM continue to execute on the CPU after it finished booting, "under" the kernel, preempting it as they please.

[yjftsjthsd-h]

I mean, it's not uniformly literally technically identical, but yes, an Android phone running its OS in ring 0 while other OSs run in other VMs on top of the EL2 (ring -1) hypervisor under the supervision of the Secure Monitor in L3 (ring -2) is very much in the same boat.

Suggested reading:

* https://www.maven-silicon.com/blog/privilege-levels-in-arm-a...

* https://projectzero.google/2017/02/lifting-hyper-visor-bypas...

* https://en.wikipedia.org/wiki/ARM_architecture_family#Securi...

* https://docs.samsungknox.com/admin/fundamentals/whitepaper/s... (in which Samsung uses firmware running under the kernel to protect against kernel exploits)

[M95D]

Oh, I didn't know that!

There goes freedom in the ARM world too.

[craftkiller]

The person I was replying to was specifically asking for ACPI for ARM and they specifically stated their negative opinion of device tree.

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