20+ China-based companies join UEFI Forum

They could have at least included the list of the 20+ companies in the press release. ;-(

In anticipation of the first China-based UEFI event in ten years, over 20 new members in China joined the UEFI Forum—indicating significant interest in UEFI technology in the greater China region. Additionally, in attendance from the region were prominent member companies including H3C and Inspur, Lenovo, Loongson Technology Corporation Limited, and Sugon.



UEFI Plugfest slides uploaded


Tim Lewis of Insyde has a blog post with an update for the UEFI plugfest. *Multiple* presentations on security!!

 State of UEFI – Mark Doran (Intel)
 Keynote: China Information Technology Ecosystem – Guangnan Ni (Chinese Academy of Engineering).
 The Role of UEFI Technologies Play in ARM Platform Architecture – Dong Wei (ARM)
 ARM Server’s Firmware Security – Zhixiong (Jonathan) Zhang, Cavium
 SMM Protection in EDK II – Jiewen Yao (Intel)
 Server RAS and UEFI CPER – Mao Lucia and Spike Yuan (Intel)
 A More Secure and Better User Experience for OS-based Firmware Update – David Liu (Phoenix)
 UEFI and IoT: Best Practices in Developing IoT Firmware Solutions – Hawk Chen (Byosoft)
 Establishing and Protecting a Chain of Trust with UEFI – David Chen (Insyde)
 Implementation of Hypervisor in UEFI Firmware – Kangkang Shen (Huawei)
 Lessons Learned from Implementing a Wi-Fi and BT Stack – Tony Lo (AMI)
  UEFI Development Anti-Patterns – Chris Stewart (HP)



I just noticed a new UEFI bootkit on Github which I’d never heard of:

“UEFI-Bootkit: A small bootkit designed to use as little ASM as possible. Thanks to pyro666”


I sent a FYI to the UEFI Security group before posting about it to this blog, in the name of responsible disclosure. Dick Wilkins of Phoenix Technologies– and of the UEFI Forum’s Security Response Team (USRT) — replied with his input on the code:

“I just took a quick look at this code in github. It looks like the typical UEFI application that changes the configuration and could cause unexpected things to boot. The unexpected stuff could damage the system and then continue to boot up normally but compromised. This is exactly why Secure Boot was needed. If Secure Boot is disabled (or not implemented), there are many ways to insert code into the boot path and compromise a system. If Secure Boot is enabled, this code and any code like it would not be properly signed and would never run. There is nothing new here. This is why end users must be discouraged from disabling secure boot and running non UEFI Secure Boot aware systems.”


UEFI Forum plugfest videos online

The PDFs of the presentations were uploaded earlier, now the videos are online on YouTube.

The presentations are all very interesting. The Microsoft talk gives more background on clarifying the “Secure Boot” golden keys being leaked. Style points go to that speaker with his ‘golden key’ necklace. 🙂




UEFI Forum publishes plugfest presentation PDFs

Recently the UEFI Forum had a plugfest. They just uploaded the slides of the presentations. I think the videos are expected in a few weeks as well.

UEFI Fall Plugfest – September 20-22, 2016
* Redfish Configuration of UEFI HII Settings – Mike Rothman (Intel) and Samer El Haj Mahmoud (Lenovo)
* Out of Band BIOS Remote Management – Matthew Krysiak (AMI)
* UEFI Forum Update – Dong Wei (HPE)
* Microsoft UEFI Security Updates – Scott Anderson, Suhas Manangi, Nate Nunez, Jeremiah Cox, and Michael Anderson (Microsoft)
* Tianocore 2016 Updates -Tony Mangefeste (Intel)
* UEFI Network and Security Update – Vincent Zimmer (Intel)
* Updated TCG TPM 2.0 Specs – Dick Wilkins (Phoenix Technologies Ltd.)
* ARM Trusted Firmware ARM UEFI SCT Update – Charles Garcia-Tobin (ARM)


UEFI Forum updates PI spec

There’s a bit more to be gleaned from reading the above two twitter threads.


UEFI Forum updates Secure Boot revocation database?

I wish I knew some more authoritative sources of news for this Microsoft Secure Boot story… 😦 The below post implies that the UEFI Forum’s Secure Boot recovation list file has been updated in response to recent news.

I REALLY wish the UEFI Forum would *announce* when they update their Secure Boot revocation list, and include version history to the changes, and keep older releases available for diffing against current one. It seems something this important should not be under public version control so you can see when keys come and go, and why. The current web page on this database should include information about the entries in the current database, and show changes and why. The page for this database should include end-user information for sysadmins to apply this to their systems, I see no real documentation on this page on how to properly use this database.

excerpt from https://blog.uncooperative.org/blog/2016/08/18/secure-boot-failures-and-mitigation/

[…] In response, UEFI is distributing an updated version of the Secure Boot revocation list, aka dbx. dbx is used to remove previously granted access from a UEFI driver or application, or from a signing certificate, declaring that signature invalid or signatures with the blacklisted certificate to be invalid. This update adds 64 new new individual signature entries into dbx, raising the total to 77.  […]

UEFI Fall plugfest schedule announced

More details for this:

The details for the Fall UEFI Forum plugfest have been announced:

Out of Band BIOS Remote Management – AMI
This session will provide an overview of Out of Band BIOS remote management. The REST protocol, which allows for operations with server processes staging Out Of Band requests, can be layered on the platform interface with an integrated baseboard management controller (BMC) or with remote servers. UEFI provides extensive networking support for the pre-boot environment, including secure communication protocols like HTTPS. Checking for staged Out Of Band requests provides a highly manageable solution applicable to a variety of platform with or without a BMC.

Innovative Software Tools & Methods to Profile, Test and Optimize UEFI Firmware Improving Test Coverage and Debug Results – Kevin Davis, VP of Kernel Engineering, Insyde Software
How effective are your test tools for analyzing UEFI firmware applications? Learn how using key x86 processor capabilities and UEFI executable analysis, like Insyde’s tools can report exactly which lines of code were executed during boot.

Microsoft Security Built on UEFI Security 2.n (P1 and P2)
Attend this interactive session to learn about: The Hardware Security Test Interface (HSTI) v2, Customized Deployment of UEFI Secure Boot, including user mode, audit mode and deployment mode, Device Guard  and Credential Guard, VSM (Virtualization enabled by default), WSMT (Windows SMM Security Mitigations Table)

UEFI Network and Security Update – Vincent Zimmer, Sr. PE, Intel Corporation
How does the UEFI Forum evolve new capabilities for networking and security?  From business requirements to use-cases, threat models, and adjacent industry efforts, the Forum has evolved the footprint of capabilities in this area. This session will provide a brief history of features for networking and security, future areas of application and a depiction of how these technologies are evolving.

Update on TPM 2.0 Firmware Requirements – Dick Wilkins, Ph.D.  Phoenix Technologies Ltd.
As a follow-up to the last session at the UEFI Plugfest in Taipei, “The TPM 2.0 Specs Are Here, Now What?” the Trusted Computing Group (TCG) PC Client Working Group has incorporated several changes in their specifications, requiring updates to the functionality and the addition of new features. The updated TCG specifications will be ready for public review soon. Join this session to learn more about the upcoming enhancements and new requirements for these specifications.

More info:

new EDK2-Bugs mailing list and Tianocore bugzilla server

On the EDK2-Devel list, Mike Kenney of Intel announced the creation of the Tianocore Bugzilla Server, and the new EDK2-bugs mailing list, which tracks changes to the bug database. The Tianocore project is going to migrate from the Github bug database to their own Bugzilla-based one. The announcement mentions a special case for UEFI security issues:

There is one special Product type on the Bugzilla server called “Tianocore Security Issues”.  If you believe you have discovered a security issue, then you must enter the issue using the “Tianocore Security Issues” Product.  The issue will be evaluated to determine if it really is a security issue or not. NOTE: Never any security issue details in email.

For full details, see Mike’s post:

More info:

Hmm, No posts yet to the new list, at least nothing has been archived, yet there are 39 bugs in the database, I would have expected at least 39 posts in the archives…. The Tianocore Security Advisory list never seemed to work. The Intel Security Advisories list never seemed to work. Let’s hope the EDK2-bugs list works…

new UEFI chain-of-trust whitepaper

The UEFI Form has a new whitepaper on UEFI and the Chain of Trust:


The Chain of Trust: Keeping Computing Systems More Secure
UEFI Forum white paper explaining the Chain of Trust and its role in keeping computing systems secure



Intel FSP 2.0

Jiewen Yao of Intel submitted a 19-part patch to the UEFI Forum’s EDK2 project today, adding Intel FSP 2.0 support.

(The comments for the patch are also the first time I’ve seen a pointer to the 2.0 FSP spec. Strangely, at the moment Intel.com is down for me, though the rest of the intarwebs appears to be up, so I cannot verify the FSP PDF URL…)

This series of patch is to support FSP2.0 specification at

Some major updates include:
1) One FSP binary is separated to multiple components:
FSP-T, FSP-M, FSP-S, and optional FSP-O.
Each component has its own configuration data region.
2) All FSP-APIs use same UPD format – FSP_UPD_HEADER.
3) Add EnumInitPhaseEndOfFirmware notifyphase.
4) FSP1.1/FSP1.0 compatibility is NOT maintained.

The new Intel platform will follow FSP2.0.
The old platform can either use an old EDK branch, or move FSP1.1 support to platform directory.

We also add rename Fsp* to FspWrapper* in IntelFspWrapperPkg, to indicate that it is for FspWrapper only.

  IntelFspPkg: Update FSP header file to follow FSP2.0 spec.
  IntelFspPkg: Update FSP private header file used by FSP2.0 implementation.
  IntelFspPkg-FspCommonLib: Update FSP common lib for FSP2.0.
  IntelFspPkg/FspPlatformLib: Update FSP platform lib for FSP2.0.
  IntelFspPkg/FspSecPlatformLib: Update FSP SecPlatform lib for FSP2.0.
  IntelFspPkg/FspSecCore: Update FSP SecCore for FSP2.0.
  IntelFspPkg/FspNotifyPhase: Separate FSP NotifyPhase from DxeIpl to new module.
  IntelFspPkg: Update DEC/DSC for FSP2.0.
  IntelFspPkg/Tool: Update FSP tool for FSP2.0.
  IntelFspWrapperPkg/Ppi: Update FspInitDone to FspSiliconInitDone.
  IntelFspWrapperPkg/FspWrapperApiLib: Update FspApiLib to FspWrapperApiLib.
  IntelFspWrapperPkg/FspWrapperApiTestLib: Add ApiTestLib as hook.
  IntelFspWrapperPkg/FspWrapperHobProcessLib: Update FspHobProcessLib to FspWrapperHobProcessLib.
  IntelFspWrapperPkg/FspWrapperPlatformLib: Update FspPlatformInfoLib to FspWrapperPlatformLib.
  IntelFspWrapperPkg/FspWrapperPlatformSecLib: Align PlatformSecLib defined in UefiCpuPkg.
  IntelFspWrapperPkg/FspWrapperSecCore: Remove FspWrapperSecCore.
  IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.
  IntelFspWrapperPkg/FspWrapperNotifyDxe: Update FspNotifyDxe to FspWrapperNotifyDxe.
  IntelFspWrapperPkg: Update DEC/DSC for FSP2.0.

For more info, see the full patch sent to the EDK2-devel list:

new Microsoft ACPI table: WSMT

As mentioned earlier this week, Microsoft just released a spec for their new ACPI table WSMT (Windows SMM Security Mitigations Table):


The Windows SMM Security Mitigations Table specification contains details of an ACPI table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features. This information applies for Windows Server Technical Preview 2016, and Windows 10, version 1607. […]

Full spec:

The UEFI Forum maintains ACPI specs. AFAICT, their ACPI spec list does not yet list this new WSMT table.

Also, there’s a strange copyright in this spec:

Portions of this software may be based on NCSA Mosaic. NCSA Mosaic was developed by the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. Distributed under a licensing agreement with Spyglass, Inc.

Maybe I am just noticing this paragraph, and Microsoft always uses that on copyright pages, and does not mention other old software, only NCSA Mosaic. But why NCSA Mosaic-centric copyrights in an WSMT ACPI table?? Microsoft IE 1.0 was based on NCSA Mosaic source code, via Spyglass purchase, but that was long before EFI or ACPI. I didn’t notice anything Win9x/BIOS/ISA-PNP-centric about WSMT. :-).

In related news, Jiewen Yao of Intel has submitted the WSMT definition into the tianocore EDK-II project:

MdePkg: Add WSMT definition. This patch adds Windows SMM Security Mitigation Table @ http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx

 …/WindowsSmmSecurityMitigationTable.h            | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)


Jiewen also submitted a 12-part patch, enhancing SMM to deal with this new table:

[PATCH 00/12] Enhance SMM Communication by using fixed comm buffer. This series patches are generate to meet Microsoft WSMT table definition on FIXED_COMM_BUFFERS requirement. Before this series patches, the DXE or OS module can use any non-SMM memory as communication buffer to exchange data with SMM agent. Microsoft WSMT table has requirement to support fixed communication buffer – so that SMM agent can only support communication buffer with type EfiReservedMemoryType/EfiRuntimeServicesCode/EfiRuntimeServicesData/EfiACPIMemoryNVS, which will not be used by OS during runtime. So we clean up all SMM handler to only use these memory regions for SMM communication, and enhance check in SmmMemLib to catch the violation. This series patches are validated on real platforms with SMM enabled. This series patches are validated on OVMF ia32-x64 with SMM enabled.

For full patch, see list archives:

UEFI Forum Spring plugfest presentations uploaded

The UEFI Forum is concluding their Spring plugfest in Taipei. They’ve uploaded the 8 presentations to uefi.org:

    UEFI Forum Update – Dong Wei (HPE)
    UEFI Forum ARM Update – Mitch Ishihara (ARM)
    Improving Platform Security with UEFI Secure Boot and UEFI Variables – David Chen (Insyde Software)
    The TPM 2.0 specs are here, now what? – Dick Wilkins (Phoenix Technologies)
    Standardized Firmware for ARMv8 based Volume Servers – Jonathan Zhang (Cavium Inc.) and Robert Hsu (AMI)
    Microsoft Update for Windows Security – Jackie Chang, Tony Lin (Microsoft Corporation)
    UEFI Port to RISC-V Processor Architecture – Abner Chang (HPE)
    Tianocore 2016 Updates – Tony Mangefeste (Intel)


and look for the videos to start showing up here:

UEFI 2.6 and ACPI 6.1 specs announced

The UEFI Forum has announced the availability of the UEFI v2.6 and ACPI v6.1 specifications.

ACPI v6.1 includes:
 * Interrupt-signaled events for expanded hardware-reduced platform support and improved system-on-chip designs.
 * Standardized ARMv8-A processor support for “firmware-first” hardware error handling and reporting, including SEA and SEI notification types in the Hardware Error Source Table (HEST).

UEFI v2.6 includes:
 * Enriched ability for agents in the system to provide better user interface support prior to launching of the OS through additional Image and Font information.
 * Formal API definition for RAM Disk Protocol.
 * New Wireless MAC Connection Protocol interface simplifies wireless network support and future radio technology versions.
 * ARM error reporting extensions for the Common Platform Error Record (CPER), allowing ARMv8-A systems to implement “firmware-first” hardware error handling and reporting.

More info:

Tianocore transitioned to Github

Jordan Justen of Intel announced the transition of the Tianocore EDK2 project from Sourceforge to Github. Transition began Friday February 2nd and is apparently now complete. It is a big deal when a large codebase moved to another version control system… excerpting Jordan’s status message:
And, for months, quite a few people at Intel have been working behind the scenes to get everything ready for the transition. Thanks!

Merry EDK II Git Day!

More information:

Note there is also an #edk2 channel on OTFC, http://www.oftc.net/