Garrett: Why ACPI?

Posted Nov 2, 2023 0:57 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: Garrett: Why ACPI? by jra
Parent article: Garrett: Why ACPI?

I think he's a bit unfair. The problem with security comes down to the fact that it's hard to write secure code in general, and secure code in C in particular.

I think that Linux developers understand pretty well that a modern computer is a mess of multiple smaller computers, and Linux tries to do all the right stuff with the IOMMU and defensive programming. But it's almost inevitable that drivers that are tens of thousands of lines long will have vulnerabilities. Especially because it's so hard to test for them, you can't just fuzz the device-side for something like WiFi or GPUs.

Garrett: Why ACPI?

Posted Nov 2, 2023 1:32 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

> But it's almost inevitable that drivers that are tens of thousands of lines long will have vulnerabilities.

It's not that the _driver_ had a vulnerability; it's that the _device itself_ reconfigured a shared peripheral out from underneath Linux's nose. There's nothing that Linux (or any other "OS" software) can do to protect itself against a peripheral that has full bus-master DMA access to the main system bus. This sort of hardware-level vulnerability requires hardware-level protection.

(Of course, in the real world, these subsystems actually consider the entire Linux-running core complex to be the non-trustworthy one, and are set up to protect _themselves_ from Linux. Because cellular radios and DRM keys are more precious than any possible user data)

> Especially because it's so hard to test for them, you can't just fuzz the device-side for something like WiFi or GPUs.

That will do f-all when a device has full access to the system bus and can arbitrarily access the entire physical address space.

Garrett: Why ACPI?

Posted Nov 2, 2023 2:27 UTC (Thu) by cypherpunks2 (guest, #152408) [Link] (1 responses)

> There's nothing that Linux (or any other "OS" software) can do to protect itself against a peripheral that has full bus-master DMA access to the main system bus. This sort of hardware-level vulnerability requires hardware-level protection.

Enabling the IOMMU (properly-configured VT-d2 with x2APIC and IR support[1], and ATS disabled[2]) is the very hardware-level protection that protects against this. While the peripheral does have bus master, the DMAR ACPI tables allow the IOMMU to remap any requests from the peripheral. This assumes the driver doesn't have any serious bugs[3], but will protect against arbitrary memory access, despite the peripheral having bus master.

And even if a device is not isolated with the IOMMU, while it can still toggle its own bus master bit in the PCIe command register by itself, the DMA requests won't be forwarded by the PCI bridge unless it _too_ has its bus master bit set (which is not something the peripheral can control on its own).

[1] https://invisiblethingslab.com/resources/2011/Software%20...
[2] https://cloud.google.com/blog/products/gcp/fuzzing-pci-ex...
[3] https://www.ndss-symposium.org/wp-content/uploads/2019/02...

Garrett: Why ACPI?

Posted Nov 2, 2023 11:56 UTC (Thu) by pizza (subscriber, #46) [Link]

> Enabling the IOMMU (properly-configured VT-d2 with x2APIC and IR support[1], and ATS disabled[2]) is the very hardware-level protection that protects against this.

You're thinking x86 PC, whereas this hardware is a complex SoC with many sets of CPU cores, only one of which runs Linux. The specific co-processor in question is *directly attached to the main system/processor bus* (ie not PCIe) and has its own dedicated IOMMU under its own control.

Again, the threat model for this system is that this co-processor needs to be protected from *linux*, not the other way around. This peripheral has *higher* privileges than the Linux kernel, so any protections Linux can set up, this thing can overwrite.

And *that* is the point of the talk -- Linux isn't the "real" operating system on modern SoCs (and arguably, even x86 PCs/servers) and we need to disabuse ourselves of that delusion ASAP.

Garrett: Why ACPI?

Posted Nov 2, 2023 15:08 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> It's not that the _driver_ had a vulnerability; it's that the _device itself_ reconfigured a shared peripheral out from underneath Linux's nose.

No, it was the driver mistakenly allowing the peripheral to request access to all of the RAM, bypassing the SMMU (that's the name of IOMMU for ARM).

> This sort of hardware-level vulnerability requires hardware-level protection.

There is such protection in place, it was not used correctly. There's nothing special about modern ARM SOCs, they all potentially have the same guarantees as x86. Most of the devices in SOCs are connected through internal serial buses like SPI or I2C, anyway. It's mostly high-bandwidth devices that need some special attention.