ACPI tables contain ACPI Machine Language, or AML, which is executed by an interpreter in the kernel at boot. Certain ACPI tables, such as the DSDT, are necessary to support hardware ACPI events such as resuming a suspended system. To access these tables, which are stored on the BIOS flash, the kernel maps them to memory, causing any access to the tables to re-read from the actual flash chip itself every time the access occurs. This means that an attacker who modifies the BIOS flash contents while a system is running may be able to activate the payload by triggering an ACPI event, causing the newly modified malicious DSDT AML being re-read and executed.

I know precious little about ACPI, but this has always been my understanding. My questions:

  • Am I correct that an ACPI table modified at runtime will be executed during certain ACPI events?

  • If this is true, then what specific events can trigger this (resume from S3, hotplugs, etc.)?

  • Which tables are re-read from flash? Is it only the DSDT? The SSDT? Is it system-specific?

This is relevant because, if my understanding is correct, it would allow an attacker that can modify the BIOS flash to bypass TPM-based SRTM protection at runtime, even if the CRTM is read-only.

  • As far as I know, ACPI tables are created/copied in RAM (eg: that's what e820 can account for) so one would not even need to change the flash. But if you are talking about TXT, the BIOS is measured so the ACPI tables are valid. The bootloader and the kernel can also be measured and so the OS is also valid. Everything that happens after a valid OS is booted is not covered by TXT and thus by the S(C)RTM. The OS is responsible for making sure the ACPI table are not tainted. That said, I don't know if ... – Margaret Bloom Mar 21 at 17:32
  • ... Linux or Windows "cache" the ACPI tables. Since they must be parsed is reasonable to expect some form of processing and that this is eventually saved and reused. Regarding when AML is executed, I'd had to brush up on the spec but almost any method of an object on a namespace can contain AML. So, AML may need to be executed to, e.g., to a device to sleep or query its status, in response to the SCI, to query the battery and so on. – Margaret Bloom Mar 21 at 17:34
  • @MargaretBloom The Linux kernel command line option acpi=copy_dsdt (commit) states in the documentation that it copies DSDT to memory, which implies to me that it is not shadowed in RAM (but I'm not sure, as ACPI is something I know little about). – forest Mar 21 at 22:25
  • @MargaretBloom so one would not even need to change the flash – Yes, but a physical attacker would not necessarily have write access to RAM while the system is running, but they would have write access to the BIOS (and thus ACPI tables) in flash/EEPROM. – forest Mar 21 at 22:37
  • I checked one of my laptops and the ACPI tables are all created in memory. This is only anecdotal evidence but it makes sense to have the ACPI tables in memory because some ACPI features are configurable through the BIOS interface. The acpi=copy_dsdt is used to make a copy of the DSDT because some BIOSes corrupt it (which again it's strong evidence that ACPI tables are created in memory. While the flash can be reprogrammed, it'd be too cumbersome to flash a page just to update a table). – Margaret Bloom Mar 22 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.