Garrett: Why ACPI?

It doesn't change the fact that there has to be _some_ way for the hardware to perform basic initialization, enumerate storage and other I/O devices, and load the operating system. On top of that, over the past 30 years we've grown accustomed to the "hardware" providing a standard mechanism to perform operations like power management, suspend, and other things that require intimate knowledge of each unique hardware design/variation.

In ARM-land, historically there has been no such standard mechanism; a unique per-design bootloader performs low-level initialization, copies the OS image from storage, and loads it. In the olden days, the OS needed to be pre-compiled for that specific design, with what was effectively a "per-design driver" that told the OS what peripherals were present and how/where they were hooked up. The major downside to this approach is that you need explicit OS support for your hardware design before it can even _boot_.

More recent ARM moved to a devicetree, where the per-design bootloader handed a generic OS image a detailed description of the hardware. The OS still had needed to have a driver for each individual component, but no longer needed a "driver" unique to each design variation. This meant you could use a generic OS image, but that OS still needed to have device drivers for every component, including the low-level platform stuff (eg PMIC or clock generators) without which the system might not be able to boot. This still tended to require a relatively modern OS image for newer hardware designs.

This is where UEFI+ACPI comes in; it standardizes the OS<->"hardware" API so that you don't need to update the OS (and/or its drivers) every time you tweak your hardware design. The OS can just invoke the generic ACPI "power down" API instead of needing to know that this design has a FooCo X4321-b PMIC, with eight different voltage regulators (controlled by a specific set of pins) that need to be shut down in a specific sequence or the board can't be powered back up again without physically disconnecting power for five minutes.

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

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.