The UEFI Forum has released the latest version of the ACPI spec.
Some input from Nikolaj:
Finally, I Can Sleep Tonight: Catching Sleep Mode Vulnerabilities of the TPM with the Napper
Seunghun Han | Senior Security Researcher, National Security Research Institute of South Korea
Jun-Hyeok Park | Senior Security Researcher, National Security Research Institute of South Korea
[…]In this talk, we present two vulnerabilities, CVE-2017-16837 and CVE-2018-6622. The vulnerabilities we found can subvert the TPM with Advanced Configuration and Power Interface (ACPI). ACPI in PCs, laptops, and servers provide six sleeping states (S0-S5) for reducing power consumption. When the system enters the sleeping state, CPU, device, and RAM are powered off. Since the system powers the components off including security devices, the system should reinitialize them while waking up and this could be the attack surface. We found vulnerabilities on this attack surface without physical access. To mitigate the vulnerabilities, we also present countermeasures and a new tool, “Napper,” to check the vulnerabilities of the TPM. Napper is a bootable USB device based-on Linux, and it has a custom kernel and a vulnerability checking software. When you boot a system with the Napper, it makes your system to take a nap to check the vulnerabilities and to report the result to you.
Written in C. Requires Ruby. There are a few BGRT tools, this one is about a week old.
* ACPICA: Update to version 20181031
* olog:olog.json: Update OPAL skiboot errors to check on olog scan
* acpi: button: check fixed hardware & control method power buttons
* kernelscan: add -k option to specify klog json filename
* README: update package dependency notes for RHEL
* acpica: fix linker issues when building with ACPI disabled
* src/lib: add module probing helper functions
* lib: fwts_efi_module: use the new module loading helper functions
* lib/fwts_cpu: use new use the new module loading helper functions
* snapcraft: update confinement and plugs
* lib: fwts_coreboot_cbmem: don’t use void * pointer arithmetic
* lib: fwts_coreboot_cbmem: shift UL values rather than signed int values
* lib: fwts_log: shift UL values rather than signed int values
* acpi: syntaxcheck: rename syntaxcheck_table to syntaxcheck_single_table
* dmicheck: fix Maximum Capacity checking range
* mcfg: fix MMIO config space checking
* madt: fix the Local APIC NMI processor UID checking
* auto-packager: mkpackage.sh: add disco
Primary usage: run it from a initcpio hook (on archlinux) to ask for the LUKS passphrase, while showing the firmware picture. The passphrase is saved in a file (/crypto_keyfile.bin) which the encrypt hook uses to unlock LUKS volumes.
ALi Aladdin V ACPI Throttle Utility V0.10
ALi5THT is a computer slowdown utility. It uses the Motherboard southbridge ACPI functions to introduce wait states, and being hardware based does not run in The background. This package allows one to use ACPI throttling on ALi Aladdin V motherboards.[…]
Lots of news are filled with news about the latest version of CHIPSEC released. I don’t see that, but there are some interesting new checkins w/r/t ACPI support:
ACPI_TABLE_SIG_BGRT = ‘BGRT’
ACPI_TABLE_SIG_LPIT = ‘LPIT’
ACPI_TABLE_SIG_ASPT = ‘ASPT’
+ACPI_TABLE_SIG_FIDT = ‘FIDT’
+ACPI_TABLE_SIG_HEST = ‘HEST’
+ACPI_TABLE_SIG_BERT = ‘BERT’
+ACPI_TABLE_SIG_ERST = ‘ERST’
+ACPI_TABLE_SIG_EINJ = ‘EINJ’
+ACPI_TABLE_SIG_TPM2 = ‘TPM2’
+ACPI_TABLE_SIG_WSMT = ‘WSMT’
+ACPI_TABLE_SIG_DBG2 = ‘DBG2’
+ACPI_TABLE_SIG_NHLT = ‘NHLT’
+ACPI_TABLE_SIG_MSCT = ‘MSCT’
+ACPI_TABLE_SIG_RASF = ‘RASF’
+ACPI_TABLE_SIG_SPMI = ‘SPMI’
+ACPI_TABLE_SIG_OEM1 = ‘OEM1’
+ACPI_TABLE_SIG_OEM2 = ‘OEM2’
+ACPI_TABLE_SIG_OEM3 = ‘OEM3’
+ACPI_TABLE_SIG_OEM4 = ‘OEM4’
+ACPI_TABLE_SIG_NFIT = ‘NFIT’
as well as some new SGX support… Fun!
“This bug deserves more attention than it is currently receiving. It should be pinned in every forum with an affected machine, so that owners of those machines will be aware that it exists. It is currently squirreled away in the T series forum, under the outdated title “T480s – ACPI bug”. I have asked that the title be updated and received no response, which is why I’m posting this here.[…]
There’s a bug in the ACPI tables that affects all of the machines listed in the title. The bug causes heavy CPU usage on one thread due to frequent ACPI interrupts. The symptoms are a slow system, and high CPU temperatures (idles around 65 degrees Celsius). Some operating systems may mitigate the symptoms, but the bug is present regardless.
The following circumstances trigger it:
-powering on the laptop
-waking from suspend (and possibly hibernate – untested)
The following actions prevent it:
-reboot the laptop (temporary fix)
-disable thunderbolt in the UEFI settings (permanent fix – with latest UEFI updates)
The official UEFI update changelogs for all of these machines make explicit mention of this issue: “-(Fix) Fix an issue where system may become hot by system interrupts when Thundrebolt is disabled in ThinkPad Setup – Security – I/O Port Access.”[…]
Alex Hung of Canonical — and one of the FirmWare Test Suite developers — has a new blog post, showing how to debug ACPI on recent builds of Ubuntu:
ACPICA is a project that provides an operating system (OS)-independent reference implementation. It also contains a list of utilities such as ASL compiler (iasl), acpiexec (an AML emulator) and so on. However, debugging AML on Linux in real time wasn’t provided in ACPICA … until Linux Kernel 4.13. The aml-debugger.txt the instruction of how to enable AML debugger, is available at Documentation/acpi/ in Linux kernel source code. In short, two things are required to run AML debugging. […] While compiling a custom-build kernel with the above two config is nothing new to kernel developers, it is often inconvenient for firmware developers who need to verify ACPI implementation in their firmware. Fortunately, Ubuntu 18.04 (x64) enables these two config by default, and one can run acpidbg on Ubuntu 18.04 – even on Ubuntu Live from USB too! Executing acpidbg on Ubuntu 18.04 is very straight-forward[…]
A library to parse ACPI tables and AML, written in Rust. Designed to be easy to use from inside a kernel written in Rust, and fully tested. Acpi is currently very early in development, will be highly unstable and is next to useless for actually parsing ACPI or AML.
Lux is a new Unix-like operating written for the PC, aiming for high performance with minimal requirements. Lai, the Lux ACPI Implementation, is an implementation of ACPI’s Machine Language (AML) written for use with lux, but with portability in mind. As such, lai is portable and OS-independent. It depends on a few OS-specific functions, and so a small layer is written for each OS lai is to be used with, and this requires no changes to the core code of lai.
Please leave a comment on this blog if you can find their spec, UEFI does not have a pointer to it.
This software is useful if:
* you have a (probably self-encrypting) hard disk / solid state drive that supports the (S)ATA SECURITY command set
* you want to boot from this drive.
* your motherboard’s BIOS does not support asking the user for a hard disk password at startup
* you don’t want to buy a new motherboard.
* the hard disk controller of your motherboard supports AHCI.
Rafael J. Wysocki of Intel submitted a patch to Linux ACPI for a ACPI Time and Alarm Device (TAD) driver:
Introduce a driver for the ACPI Time and Alarm Device (TAD) based on Section 9.18 of ACPI 6.2. This driver only supports the system wakeup capabilities of the TAD which are mandatory. Support for the RTC capabilities of the TAD will be added to it in the future. This driver is entirely sysfs-based. It provides attributes (under the TAD platform device) to allow user space to manage the AC and DC wakeup timers of the TAD: set and read their values, set and check their expire timer wake policies, check and clear their status and check the capabilities of the TAD reported by AML. The DC timer attributes are only present if the TAD supports a separate DC alarm timer. The wakeup events handling and power management of the TAD is expected to be taken care of by the ACPI PM domain attached to its platform device.
The ACPI Time and Alarm (TAD) device is an alternative to the Real Time Clock (RTC). Its wake timers allow the system to transition from the S3 (or optionally S4/S5) state to S0 state after a time period elapses. In comparison with the RTC Alarm, the TAD provides a larger scale of flexibility in the wake timers. The time capabilities of the TAD maintain the time of day information across platform power transitions, and keep track of time even when the platform is turned off.
More info: linux-acpi list archives, http://vger.kernel.org/majordomo-info.html
ARM has submitted a patch to UEFI’s Tianocore which adds a “Dynamic Tables” framework that abstracts ACPI amongst other things… Readme excerpt of patch below:
This patch introduces a branch for implementing Dynamic Tables Framework.
To reduce the amount of effort required in porting firmware to new platforms, we propose this “Dynamic Tables” framework. The aim is to provide an example implementation capable of generating the firmware tables from an external source. This is potentially a management node, either local or remote, or, where suitable, a file that might be generated from the system construction. This initial “proof of concept” release does not fully implement that – the configuration is held in local UEFI modules.
The dynamic tables framework is designed to generate standardised firmware tables that describe the hardware information at run-time. A goal of standardised firmware is to have a common firmware for a platform capable of booting both Windows and Linux operating systems.
Traditionally the firmware tables are handcrafted using ACPI Source Language (ASL), Table Definition Language (TDL) and C-code. This approach can be error prone and involves time consuming debugging. In addition, it may be desirable to configure platform hardware at runtime such as: configuring the number of cores available for use by the OS, or turning SoC features ON or OFF.
The dynamic tables framework simplifies this by providing a set of standard table generators, that are implemented as libraries. These generators query a platform specific component, the ‘Configuration Manager’, to collate the information required for generating the tables at run-time.
The framework also provides the ability to implement custom/OEM generators; thereby facilitating support for custom tables. The custom generators can also utilize the existing standard generators and override any functionality if needed.
The framework currently implements a set of standard ACPI table generators for ARM architecture, that can generate Server Base Boot Requirement (SBBR) compliant tables. Although, the set of standard generators implement the functionality required for ARM architecture; the framework is extensible, and support for other architectures can be added easily.
The framework currently supports the following table generators for ARM:
* DBG2 – Debug Port Table 2
* DSDT – Differentiated system description table. This is essentially a RAW table generator.
* FADT – Fixed ACPI Description Table
* GTDT – Generic Timer Description Table
* IORT – IO Remapping Table
* MADT – Multiple APIC Description Table
* MCFG – PCI Express memory mapped configuration space base address Description Table
* SPCR – Serial Port Console Redirection Table
* SSDT – Secondary System Description Table. This is essentially a RAW table generator.
[…]Please create a branch called ‘dynamictables’ in edk2-staging.[…]
More info: see the “[PATCH] Branch to implement Dynamic Tables Framework” thread on the edk2-devel list by Sami Mujawar. And look for above branch to be created.
Hmm, it appears the links to the archives on the URL provided in the mailing list posts is not valid:
V1 from Oct2017:
* ACPICA: Update to version 20180209
* uefirtvariable: add test for EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS attribute
See full announcement for list of bugfixes.
In related news, LUV has picked up the latest FWTS.
This is a companion tool to Linux Thermal Daemon (thermald). This tool tries to reuse some of the tables used by “Intel ® Dynamic Platform and Thermal Framework (Intel® DPTF)” by converting to the thermal_conf.xml format used by thermald.
Megha Dey of Intel announced the v2.2-rc2 release of LUV, Linux UEFI Validation. Excerpts of announcement below, for full announcement, see LUV mailing list post.
Two main new features:
Dump list of Device-Specific Methods:
DSM (Device Specific Method) as defined in ACPI spec is a control method that enables devices to provide device specific control functions that are consumed by the device driver. DSM’s are optional on a platform and they are optional to be consumed by OS. Both these points mean that a kernel developer might be unaware of these DSM’s and hence might never use them in their device driver. By adding this feature, LUV could be used as a vehicle to educate kernel developers about these DSM’s. A device driver developer, from the list of DSM’s provided by LUV, could then evaluate the usefulness of a DSM and then decide if it needs to be used or left as an option.
Add tests in bits to detect Machine Check Errors:
Machine Check Error (MCE) test is a way to find the errors generated by the hardware or any specific subsystem(s). The value of these tests is that it detects any MCEs that might have occurred before Linux starts to boot. Hence, if detected, they were caused by hardware or possibly BIOS.