Hacker News new | ask | show | jobs
by craftkiller 103 days ago
> can you even have something similar to IBM PC with ARM

Yes, it's called SBBR which requires UEFI and ACPI. It is more common on server hardware than on consumer-grade embedded devices. The fact that it is not ubiquitous is really holding back ARM.

1 comments

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.

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

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

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)

Oh, I didn't know that!

There goes freedom in the ARM world too.

The person I was replying to was specifically asking for ACPI for ARM and they specifically stated their negative opinion of device tree.
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.
Which x86 devices ship with a free UEFI/ACPI? Or even allow users to replace the preinstalled UEFI/ACPI with a free one?
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
> 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

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.
What do you mean by "Dangerous capabilities"?
Could you please describe the meaningful difference between SMM and Trustzone, or why the properties of UEFI and ACPI are dangerous?