New ACPI IDs for November: Nexstgo and Insyde

Here’s the list of new ACPI specs for 2017 (so far), 2 new entries in November, first update since Summer:

Company ACPI ID Approved on Date
VR Technology Holdings Limited 3GVR 01/19/2017
Exar Corporation EXAR 02/28/2017
Coreboot Project BOOT 02/28/2017
Marvell Technology Group Ltd. MRVL 05/25/2017
IHSE GmbH IHSE 06/22/2017
Insyde Software INSY 11/10/2017
Nexstgo Company Limited NXGO 11/13/2017 (XLS download)

For the 2 new entries, I can’t find any data on what their ACPI tables do, nor where their specs are:

It is a shame that the spreadsheet doesn’t have a column with more useful info, eg: URL to the vendor’s spec, perhaps which HW/OS it is valid for, which version of ACPI it requires, flag if table has FWTS test, license of vendor’s spec (eg, click-through EULA required for some ARM/MSFT/TCG docs), etc.

FWTS 17.11.00 released (and added to LUV)

The November 2017 release of FirmWare Test Suite is out, with many ACPI changes, and a few UEFI changes.

New Features:
* acpi: devices: add a new test for acpi ec device
* acpi: devices: add a new test for ACPI AC adapter device
* acpi: devices: add a new test for ACPI battery device
* acpi: devices: add a new test for smart battery device
* acpi: devices: add new tests for power and sleep button devices
* acpi: madt: check GICD’s system vector according to mantis 1819 (ACPI 6.2a)
* acp: nfit: add platform capability according to manit 1831 (ACPI 6.2a)
* lib: add new large resource data type for _CRS methods
* acpi: sdev: add ACPI SDEV test (mantis 1632)
* acpi: dppt: add ACPI PDTT test (mantis 1576)
* acpi: devices: add new tests for lid device
* acpi: devices: add new tests for ambient light sensor device
* acpi: devices: add new tests for time and alarm device
* acpi: devices: add new tests for wireless power calibration device
* acpi: add tests for _SRT control method
* auto-packager: add bionic
* fwts: add bash command-line completion
* Add ACPI 1.0 RSDP test to make sure RSDT field isn’t null
* ACPICA: Update to version 20171110
* uefi: uefidump: add dumping for BluetoothLE device path
* uefi: uefidump: add dumping for DNS device path
* uefi: uefibootpath: add test for BluetoothLE device path
* uefi: uefibootpath: add test for DNS device path

See full announcement for list of few-dozen bugfixes.

Full announcement:

In related news,  Gayatri Kammela has added this updated FWTS to LUV.

Update FWTS to version v17.11.00

Full patch:

Fall UEFI Plugfest agenda

The Fall UEFI Plugfest is happening, a week of interop testing with UEFI vendors, along with some presentations. The presentation abstracts are below, see the full itenary for speaker bios.

“Last Mile” Barriers to Removing Legacy BIOS (Intel)
While UEFI has become a dominant standard since its introduction in 2005, many use cases still rely on compatibility with PC/AT Legacy BIOS. These legacy corner cases are a barrier to completing the transition to modern firmware standards. Intel has identified maintaining compatibility as an issue for platform security and validation costs, and plans to eliminate legacy BIOS elements in our 2020 data center platforms. This session discusses “last mile” gaps for 16-bit compatibility and identifies UEFI capabilities that the industry can promote as alternatives, including HTTPS Boot, OS Recovery, and Signed Capsule Update.

UEFI Firmware – Security Concerns and Best Practices (Phoenix)
(no Abstract)

Strategies for Stronger Software SMI Security in UEFI Firmware (Insyde)
Avoid design errors and software coding pitfalls when implementing SMI handlers. Device manufacturers customize UEFI firmware using new runtime interfaces that are implemented using software SMIs. Heavy customization, tight deadlines and poor code implementation can accidentally allow malware to abuse the power of SMM. This session focuses on four common software SMI vulnerabilities and how to change your UEFI firmware and applications to avoid them.

Advances of UEFI Technologies in ARM Systems (ARM)
This session will discuss the ARM-related interfaces defined in the latest UEFI and ACPI specifications, the requirements of the UEFI and ACPI interfaces for the SBBR Specification, and the use of UEFI SCT and FWTS in the SBBR compliance test. Also, discussed will be the required UEFI interfaces for the embedded space when the separation of the device and OS development is desired.

Introduction to the Self-Certification Test (SCT) in UEFI World (Canonical and Intel)
The UEFI Test Working Group (UTWG) endorses two test suites: Firmware Test Suite (FWTS) and the UEFI Self-Certification Test (SCT). FWTS is focused on validating Linux compatibility, and is endorsed by UTWG for ACPI validation. The UEFI SCT is designed to validate firmware and driver behavior per the UEFI Specification. This session demonstrates the operation of both tools, and discusses how they use open source models to improve test quality.

Firmware Test Suite Introduction: Uses, Development, Contribution and GPL (Canonical)
Firmware Test Suite (FWTS) is the recommended ACPI 6.1 Self-Certification Test (SCT). This command line tool is easy to use and provides explanatory and informative. Its open-source nature allows developers to add new tests easily, and many code examples such as ACPI, UEFI and SMBIOS are available for references. Code contribution are appreciated and technical discussion and code reviews on the mailing list are answered by an active community. As licensed by GPL, FWTS ensures it is available and suitable to everyone who wants to use it publicly and privately.

NFC is a technology that has permeated many aspects of everyday life. Using NFC, you can now pay with your phone or enter secure building areas. However, the UEFI specification lacks any implementation of NFC. AMI will cover a proposed solution for NFC implementation in UEFI, how to best fit NFC into the UEFI specification, and potential use cases.

Edk2 Platforms Overview (Linaro)
For a couple of years now, the Linaro OpenPlatformPkg repository has been used to collate a number of (at least partially) open source EDK2 platform ports. However, with a now properly defined process for the TianoCore edk2-platforms and edk2-non-osi repositories, these platforms are now moving over there and OpenPlatformPkg. This session will discuss the process, the current state of things and the practicalities of working with edk2-platforms.

UEFI Manageability and REST Services (HPE and Intel)
With the increase in platform firmware complexity and capabilities, there is an increased need to standard firmware manageability is increasing. The UEFI 2.7 Specification defines REST services to provide secure solutions for managing modern platforms. This session describes enterprise configuration scenarios, discusses implementation gaps in the UEFI specification, and proposes enhancements related to vendor-specific REST services.

“Linux/Acpi.A!tr”: Linux ACPI malware?

I noticed this on an AV vendor’s site, about some Linux-centric (?) ACPI malware. Wish there was more info on it. If you have more details, please leave a Comment on this blog, thanks!

ID 7546097
Released Oct 26, 2017

Linux/Acpi.A!tr is classified as a trojan.

A trojan is a type of malware that performs activites without the user’s knowledge. These activities commonly include establishing remote access connections, capturing keyboard input, collecting system information, downloading/uploading files, dropping other malware into the infected system, performing denial-of-service (DoS) attacks, and running/terminating processes. The Fortinet Antivirus Analyst Team is constantly updating our descriptions. Please check the FortiGuard Encyclopedia regularly for updates.

ACPI 6.2 errata A released

FWTS is the recommended ACPI test tool by the UEFI Forum!

Here’s the info from the changelog:
Missing space in title of ACPI RAS Feature Table (RASF)
Typos in Extended PCC subspaces (types 3 and 4)
Add a new NFIT Platform Capabilities Structure
PPTT ID Type Structure offsets
Remove bits 2-4 in the Platform RAS Capabilities Bitmaptable
Region Format Interface Code description
Remove support for multiple GICD structures
PDTT typos and PPTT reference Revision History
Minor correction to Trigger Action Table
General Purpose Event Handling flow

If you really want to understand what has changed in the ACPI and UEFI specs, you need to join the UEFI Forum, so you can access the Mantis bug database and understand what the Mantis numbers in the ACPI and UEFI spec revision history refer to…


Linux kernel ACPI-centric CVE-2017-13694: Awaiting Analysis

Source: MITRE
Last Modified: 08/25/2017

This vulnerability is currently awaiting analysis.

The acpi_ps_complete_final_op() function in drivers/acpi/acpica/psobject.c in the Linux kernel through 4.12.9 does not flush the node and node_ext caches and causes a kernel stack dump, which allows local users to obtain sensitive information from kernel memory and bypass the KASLR protection mechanism (in the kernel through 4.9) via a crafted ACPI table.

CVE-2017-11472: Linux kernel ACPI KASLR vulnerability

The acpi_ns_terminate() function in drivers/acpi/acpica/nsutils.c in the Linux kernel before 4.12 does not flush the operand cache and causes a kernel stack dump, which allows local users to obtain sensitive information from kernel memory and bypass the KASLR protection mechanism (in the kernel through 4.9) via a crafted ACPI table.

[…]This causes a security threat because the old kernel (<= 4.9) shows memory locations of kernel functions in stack dump, therefore kernel ASLR can be neutralized. To fix ACPI operand leak for enhancing security, I made a patch which removes the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the deletion code unconditionally.[…]


Firmware Test Suite 17.07.00 released

Today Alex Hung of Canonical announced the latest release of FWTS. The list of New Features appears to all be ACPI-centric:

* acpi: bgrt: update according to acpi 6.1 errata (mantis 1577)
* acpi: method: update _PSD and _TSD tests according to ACPI 6.1 errata
* acpi: rsdp: revision 1 must have length 20 according to ACPI 6.1 errata
* acpi: method: Add _CPC revision 3 according to ACPI 6.2 (mantis 1611)
* acpi: hest: add new type 11 introduced in ACPI 6.2 (mantis 1649)
* acpi: srat: add new type 4 according to ACPI 6.2 (mantis 1656)
* acpi: method: update _GCP according to ACPI 6.2 (mantis 1703)
* acpi: hest: add notification type 11 according to ACPI 6.2 (mantis 1731)
* acpi: fadt: update minor version to 2 for ACPI 6.2 (mantis 1769)
* acpi: hest: add checks for GHES_ASSIST flag value in ACPI 6.2 (mantis 1674)
* acpi: wsmt: add wsmt test according to ACPI 6.2 (mantis 1585)
* ACPICA: Update to version 20170629
* acpi: tpm2: Add additional start method values
* acpi: iort: Add PMCG support

See the full announcement for list of Fixed Bugs (which aren’t ACPI-centric).

UEFI Forum recommends FWTS for it’s ACPI tests

FWTS has had ACPI tests for a while, and it’s basically the best public set of ACPI tests available. Better than anything the UEFI Forum has, like the SCTs. They’ve been using FWTS in the UEFI plugfests for a while, for ACPI purposes. Now the UEFI Forum is more formally recommending FWTS. Alex Hung of Canonical announces a new milestone for FWTS, the FirmWare Test Suite:

FWTS 17.03.00 is recommended as the ACPI 6.1 SCT

We have achieved another important milestone! The UEFI Board of Directors recommends Firmware Test Suite (FWTS) release 17.03.00 as the ACPI v6.1 Self-Certification Test (SCT), More information is available at:
Thank you all for who contributed patches, reported bugs, provided feedbacks and used FWTS in your work.

Thanks, FWTS, for having the best ACPI tests available!


Full announcement:


Nikolaj on recent UEFI/ACPI spec updates

William’s blog post on Nikolaj’s comments are more readable than below post:

Nikolaj has over a dozen tweets showcasing the interesting new features in the latest UEFI and ACPI specs. Click on the above Twitter URL to see the full set.


UEFI updates specs

The UEFI Forum has updated their specs.

UEFI Spec v2.7

PI v1.6

ACPI v6.2

SCT v2.5A

Linux kernel patch for ACPI HMAT support

Ross Zwisler of Intel posted a new patch to the Linux kernel, with support for the ACPI 6.2 HMAT (Heterogeneous Memory Attribute Table).

This series adds kernel support for the Heterogeneous Memory Attribute Table (HMAT) table, newly defined in ACPI 6.2. The HMAT table, in concert with the existing System Resource Affinity Table (SRAT), provides users with information about memory initiators and memory targets in the system. A “memory initiator” in this case is any device such as a CPU or a separate memory I/O device that can initiate a memory request. A “memory target” is a CPU-accessible physical address range. The HMAT provides performance information (expected latency and bandwidth, etc.) for various (initiator,target) pairs. This is mostly motivated by the need to optimally use performance-differentiated DRAM, but it also allows us to describe the performance characteristics of persistent memory. The purpose of this RFC is to gather feedback on the different options for enabling the HMAT in the kernel and in userspace.

==== Lots of details ====

See the patch, especially more details in comment documentation in part 0, on the linux-acpi mailing list posting.


new ACPI registry updates for 2017

Since I last looked[1], there has been one new company added to the ACPI registry (Marvell), and one new/updated ACPI spec (CSRT). There are also multiple new Plug and Play registry entries. (Last updated: 5/25/2017)
Coreboot Project BOOT 02/28/2017
Exar Corporation EXAR 02/28/2017
Marvell Technology Group Ltd. MRVL 05/25/2017
VR Technology Holdings Limited 3GVR 01/19/2017 (Last updated 4/27/2016)
HOYA Corporation PENTAX Lifecare Division PNT 05/25/2017
Inlife-Handnet Co., Ltd. IVR 01/19/2017
MediCapture, Inc. MVR 05/25/2017
Pabian Embedded Systems PMS 02/28/2017
Pimax Tech. CO., LTD PVR 02/07/2017
Shanghai Chai Ming Huang Info&Tech Co, Ltd HYL 02/28/2017
Shanghai Lexiang Technology Limited DPN 02/07/2017
Techlogix Networx TLN 02/28/2017
Televic Conference TCF 02/28/2017
Total Vision LTD TVL 02/07/2017
VR Technology Holdings Limited DSJ 01/19/2017

It appears the PNP_ID exported spreadsheet is not yet up-to-date with web page. By comparison, there were many more PNP IDs registered. But the ACPI exported spreadsheet is. Yet the PNP web page’s last-updated date is wrong, and the ACPI web page’s date is correct. It would be really helpful if the URL for the company would be included in the table, as well as an URL to each ACPI spec. And announce their updates. And it would be really nice if OEMs/ODMs/IHVs/IBVs/OSVs listed what ACPI version and tables they supported (yes, wishful thinking).


Microsoft updates ACPI web page

Microsoft just updated an ACPI doc of theirs:

It still refers to ACPI 5.0, while current ACPI version is at 6.1, though… No changelog, you’ll have to compare this against your archive of the old version of this web page. 🙂

Different results from reading the 3 URLs: (exports a spreadsheet)

If you use the search ability of the site, eg:

it only lists 3 tables. I’d expect it list WSMT, but it does not. Strange. Note that the ACPI search page says it was last updated 2016, so may not have current data to search?

I’d really like to see the ACPI site map the various registries to all of their specs, not have a few separate lists of company registeries, and a separate list of specs, not tied to companies.


Linux Kernel lockdown

David Howells of Red Hat has posted a 24-part patch to the Linux-(Kernel,EFI) lists, which hardens Linux from some firmware attacks.

These patches provide a facility by which a variety of avenues by which userspace can feasibly modify the running kernel image can be locked down. These include:
 (*) No unsigned modules and no modules for which can’t validate the signature.
 (*) No use of ioperm(), iopl() and no writing to /dev/port.
 (*) No writing to /dev/mem or /dev/kmem.
 (*) No hibernation.
 (*) Restrict PCI BAR access.
 (*) Restrict MSR access.
 (*) No kexec_load().
 (*) Certain ACPI restrictions.
 (*) Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot status, provided the shim isn’t insecure.  The lock-down can be lifted by typing SysRq+x on a keyboard attached to the system.[…]

See the full patch for more info:

UEFI lab at Cascadia IT Conference in Seattle March 10th

[DISCLAIMER: FirmwareSecurity is my personal blog. I work at PreOS Security.]

PreOs Security is offering a half-day training lab for System Administrators, SRE/DevOps in the Seattle area at Cascadia IT Conference, for those interested in learning about UEFI/ACPI/BIOS/SMM/etc security. Here’s the text for the training:

Defending System Firmware

Target audience: System administrators, SRE, DevOps who work with Intel UEFI-based server hardware

Most enterprises only defend operating system and application software; system and peripheral firmware (eg., BIOS, UEFI, PCIe, Thunderbolt, USB, etc) has many attack vectors. This workshop targets enterprise system administrators responsible for maintaining the security of their systems. The workshop is: an introduction to UEFI system firmware, an overview of the NIST secure BIOS platform lifecycle model of SP-(147,147b,155) and how to integrate that into normal enterprise hardware lifecycle management, and an introduction to the available open source firmware security tools created by security researchers and others, and how to integrate UEFI-based systems into the NIST lifecycle using available tools, to help protect your enterprise. It will be a 3.5 hour presentation, and at the end, you can optionally can run some tests on your laptop: Intel CHIPSEC, Linux UEFI Validation distribution (LUV-live), FirmWare Test Suite live boot distribution (FWTS-live), and a few other tools. Attendees trying to participate in the lab will need to have a modern Intel x86 or x64-based (not AMD), UEFI-based firmware, running Windows or Linux OS software. That means no AMD systems, no Apple Macbooks, no ARM systems. Any system used in the lab must have all data backed up, in case some tool bricks the device. Attendees should understand the basics of system hardware/firmware, be able to use a shell (eg, bash, cmd.exe, UEFI Shell), and able to use Python-based scripts.

announcing PreOS Security Inc. is my personal blog. I use it to post information about firmware as I come across it, in the hope that it might help others. I try to keep it impersonal and only focus on news/information, but my bias towards open source HW/FW/SW is not hard to find.

I started the blog a few years ago to learn firmware by focusing on the security perspective of firmware and learning from existing security researchers. I’d been doing OS-level driver consulting for a while, and was moving from OS-level moving down into firmware. Along the way, I’ve learned a lot and given talks and training on firmware security at LinuxFest Northwest, B-Sides PDX, SOURCE Seattle, and other places.

With great advice from both firmware engineers as well as firmware security researchers, I’ve seen an opportunity to help secure enterprises at the firmware level.

I’ve started a small new company, PreOS Security Inc., . Besides attending the last UEFI Plugfest, we’ve been mostly in ‘stealth mode’, busy working on code. We have a small group of advisors who are teaching us lots of things about security/b2b/tool startups.

We’re creating a product to help enterprises secure their system firmware, as per NIST SP 800-147 guidance. We’re leveraging the expertise of existing firmware security researchers, and some of their tools (for example CHIPSEC). We’re also writing new tools to fill in some of the gaps. Our product is currently in a pre-alpha stage, and are looking for a few enterprises who’re eager to secure their firmware to work on the alpha release.

We have a draft document on ‘enterprise firmware guidance’ that we’ll be publishing on our web site (and Github), as well as that ‘awesome firmware’ links that I’ve been promising in previous blog posts. We have some patches to existing tools that we need to upstream.

We also offer training to UEFI/ACPI device vendor QA teams, data centers, and security-minded enterprises, on using firmware security tools, and consulting to customize/integrate these tools. We’ve got a half-day training event that we’ll announce shortly.

We need a Python developer, either as a partner, or a few as contractors. Currently we have equity to offer. For more information, see: .

We’re currently self-funded, hoping to fund our product development with training/consulting. But to offer more than equity, we’ve begun looking at some other sources of funding. If there are any firmware-friendly angel investors reading this, we should talk.

Microsoft updates Secure Boot and ACPI requirements

These Microsoft pages have recently (last month) been updated. No changelog, so unclear what has changed. 😦