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:
http://www.uefi.org/uefi-acpi-export (exports a spreadsheet)

If you use the search ability of the uefi.org 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.

FirmwareSecurity.com 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.,  https://preossec.com/ . 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:  https://preossec.com/careers/ .

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.



ACPI registry updates

It looks like there have been 3 new ACPI regisrations so far this year:

Coreboot Project     BOOT     02/28/2017

Exar Corporation     EXAR     02/28/2017

VR Technology Holdings Limited     3GVR     01/19/2017



Microsoft updates Secure Boot and ACPI requirements

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