Intel security guidance: Host Firmware Speculative Execution Side Channel Mitigation

[…]This provides specific guidance for firmware based upon the EFI Developer Kit II (EDKII) and coreboot. Because this document deals with host firmware internal requirements, it is not intended to provide side channel mitigation guidance for general application developers.

Scope: This addresses bare-metal firmware runtime risks and mitigation suggestions for the bounds check bypass, branch target injection, rogue data cache load, rogue system register read, and speculative store bypass side channel methods. Our examples and context are primarily focused on ring 0 firmware runtimes (for example: EFI Developer Kit II, PI SMM, and coreboot SMM). Other firmware execution environments are out of scope.[…]

https://software.intel.com/security-software-guidance/api-app/insights/host-firmware-speculative-execution-side-channel-mitigation

more info:

https://software.intel.com/security-software-guidance/software-guidance

2 new Tianocore/EDK2 security advisories

Tianocore Security Advisories has 2 new UEFI vulnerabilities:

https://edk2-docs.gitbooks.io/security-advisory/content/

30. EDK II Authenticated Variable Bypass
Logic error in MdeModulePkg in EDK II firmware may allow authenticated user to potentially bypass configuration access controls and escalate privileges via local access.
https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-authenticated-variable-bypass.html

31. EDK II TianoCompress Bounds Checking Issues: Multiple privilege escalation vulnerabilities in TianoCompress and UEFICompress decompression algorithm may allow authenticated user to potentially manipulate stack and heap buffers via local access.

https://edk2-docs.gitbooks.io/security-advisory/content/edk-ii-tianocompress-bounds-checking-issues.html

Microsoft Project Mu: adaptation of TianoCore’s EDK2

https://github.com/Microsoft/mu_plus

https://github.com/Microsoft/mu_basecore

6 repos: https://github.com/topics/projectmu

https://microsoft.github.io/mu/faq/

https://microsoft.github.io/mu/

Project Mu is a modular adaptation of TianoCore’s edk2 tuned for building modern devices using a scalable, maintainable, and reusable pattern. Mu is built around the idea that shipping and maintaining a UEFI product is an ongoing collaboration between numerous partners. For too long the industry has built products using a “forking” model combined with copy/paste/rename and with each new product the maintenance burden grows to such a level that updates are near impossible due to cost and risk.

Project Mu also tries to address the complex business relationships and legal challenges facing partners today. To build most products it often requires both closed-source, proprietary assets as well as open source and industry standard code. The distributed build system and multi-repository design allow product teams to keep code separate and connected to their original source while respecting legal and business boundaries.

Project Mu originated from building modern Windows PCs but its patterns and design allow it to be scaled down or up for whatever the final product’s intent. IoT, Server, PC, or any other form factor should be able to leverage the content.

CVE-2018-12169: Tianocore UEFI: Unauthenticated Firmware Chain-of-Trust Bypass

“The issue was reported by Trammell Hudson”

https://edk2-docs.gitbooks.io/security-advisory/content/unauthenticated-firmware-chain-of-trust-bypass.html

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12169

https://nvd.nist.gov/vuln/detail/CVE-2018-12169

https://exchange.xforce.ibmcloud.com/vulnerabilities/150223

Tianocore Security Advisories page updated

Re: https://firmwaresecurity.com/2018/07/11/intel-releases-a-dozen-new-security-advisories/

at least one of these recent Intel bugs should also be in the Tianocore Security Advisories list, and at least one of them was just added to it:

https://legacy.gitbook.com/book/edk2-docs/security-advisory/details

eg:

https://edk2-docs.gitbooks.io/security-advisory/content/untested-memory-not-covered-by-smm-page-protection.html

VolInfo: tool to dump the contents of a UEFI firmware volume (FV)

Tianocore includes UEFI developer tools for creating ‘blobs’. But it also includes one tool useful for security researchers to examine existing Firmware Volumes. It is an OS-present tool that works on Mac/Windows/Linux, not a UEFI Shell tool.

https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/VolInfo/VolInfo.c
https://github.com/tianocore/edk2/tree/master/BaseTools/Source/C/VolInfo
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Tools-List
https://github.com/tianocore/edk2/tree/master/BaseTools/UserManuals
https://raw.githubusercontent.com/tianocore/edk2/master/BaseTools/UserManuals/VolInfo_Utility_Man_Page.rtf
https://edk2-docs.gitbooks.io/edk-ii-build-specification/content/v/release/1.27/2_design_discussion/22_uefipi_firmware_images.html
http://wiki.phoenix.com/wiki/index.php/EFI_FIRMWARE_VOLUME_HEADER

Usage: VolInfo [options] <input_file>
Display Tiano Firmware Volume FFS image information
   -h, –help — Show this help message and exit
   –version — Show program’s version number and exit
   -d [DEBUG], –debug [DEBUG] — Output DEBUG statements, where DEBUG_LEVEL is 0 (min) – 9 (max)
   -v, –verbose — Print informational statements
   -q, –quiet — Returns the exit code, error messages will be displayed
   -s, –silent — Returns only the exit code; informational and errorvmessages are not displayed
   -x XREF_FILENAME, –xref XREF_FILENAME — Parse the basename to file-guid cross reference file(s)
  -f OFFSET, –offset OFFSET — The offset from the start of the input file to start processing an FV
  –hash — Generate HASH value of the entire PE image

Tianocore releases UDK2018

Tianocore, not the UEFI Forum, has released UDK2018, the latest UEFI Dev Kit, a snapshot of the EDK-II, tied to particular revision of the specs.

https://github.com/tianocore/tianocore.github.io/wiki/UDK2018-Core-Update-Notes

https://github.com/tianocore/tianocore.github.io/wiki/UDK2018-Key-Features

https://github.com/tianocore/tianocore.github.io/wiki/UDK2018

https://github.com/tianocore/edk2/releases/tag/vUDK2018

https://github.com/tianocore-docs/Docs/blob/master/UDK/UDK2018/SecurityPkgNotes.md

 

alt archive for edk2-devel mailing list

Multiple URLs on this blog point to the Tianocore EDK2 development mailing list for more information.

https://lists.01.org/mailman/listinfo/edk2-devel

However, there’s a few broken links on the archive page for that list.

Here is more info on some changes to the list archives:

https://lists.01.org/pipermail/edk2-devel/2016-July/000000.html

Here is another source of archives of the list:

https://www.mail-archive.com/edk2-devel@lists.01.org/info.html

Thanks to the edk2-devel-owners for a pointer to this alt archive site.

 

docker-edk2-uefi: Docker container for Tianocore EDK2 dev

Container to build Tianocore EDK2 MdeModules and OVMF and run in OVMF with qemu using X over ssh

UEFI EDKII Development Environment

This docker container can be used to build projects based on the Tiano EDKII UEFI project. It is possible to selected the branch of the EDKII project to be used and compiled at container creation as well as the target architecture. Build Tools are compiled on first ssh login triggered in bashrc. qemu can be run with X over ssh. Scripts are included to build MdeModulePkg and OVMF. Script included to create base for OVMF qemu environment and start qemu (script only for x86/64 right now).[…]

https://hub.docker.com/r/geneerik/docker-edk2-uefi/

Somewhat related, I also found these UEFI/Docker options:

https://hub.docker.com/r/rojuinex/edk2-uefi/~/dockerfile/
https://hub.docker.com/r/michas2/edk2-test/~/dockerfile/

PS: Wondering what he’s been messing with UEFI on:

 

Tianocore Security Advisory 27: Minnowboard UEFI Variable Deletion/Corruption

Tianocore EDK2 security advisory page has been updated, for the first time since 2016! It looks like a single entry:

https://edk2-docs.gitbooks.io/security-advisory/content/

27. UEFI Variable Deletion/Corruption

Description: Input validation error in MinnowBoard 3 Firmware versions prior to 0.65 allow local attacker to cause denial of service via UEFI APIs.

Recommendation: This update improves input validation by firmware and is strongly recommended. For firmware development projects, incorporate the updates in https://github.com/tianocore/edk2-platforms/tree/devel-MinnowBoard3-UDK2017. When using MinnowBoard 3, update to version 0.65 or later. Updated firmware is available at https://firmware.intel.com/projects/minnowboard3

Acknowledgments: Reported by Intel.

References: CVE-2017-5699

The referenced CVE is still empty, hopefully someone at Intel/MITRE/NIST is going to take care of that sometime.

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5699
https://nvd.nist.gov/vuln/detail/CVE-2017-5699

 

UEFIStarter: framework to simplify UEFI development with TianoCore EDK2

This is a small C framework for UEFI development built on top of TianoCore EDK2. This project is not a comprehensive course in UEFI development. If you’re just starting to write UEFI code you’ll need to use additional material like the official TianoCore documentation, and the UEFI Specification. The library and UEFI applications included in this code are meant to simplify a few repetitive tasks when developing UEFI code. For example there is a configurable command line argument parser that will validate input strings and convert them into the target datatype, e.g. integers. This project started out with another UEFI development kit (gnu-efi) but eventually outgrew the original SDK, so I migrated it to TianoCore EDK2017. As a result of this there are still a few library functions included that are already built-in into TianoCore. It is my hope that this code helps anyone looking into, or starting with, UEFI development: I did that myself a few months ago and found parts of the various documentations frustratingly lacking. If I can spare you some of the headache I had I’m happy.

https://github.com/rinusser/UEFIStarter

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.

http://www.uefi.org/events/upcoming

http://www.uefi.org/sites/default/files/resources/Agenda%20and%20Session%20Abstracts%20-%20Final_Oct%2024%202017.pdf

“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 and UEFI (AMI)
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.

Intel patch for UEFI pre-memory DMA protection in PEI

Intel has submitted a V3 patch to the tianocore EDK2 project, with additional DMA protection for UEFI on Intel systems.

[PATCH V3 0/2] IntelSiliconPkg: Add Pre-Memory DMA protection in PEI

V3:
1) update the function comments of InitDmar()
2) update the function comments of SiliconInitializedPpiNotifyCallback()
3) remove duplicated BAR debug message.
4) fix the size field in the mPlatformVTdNoIgdSample structure.

V2:
Minor enhancement: Replace IsDmaProtectionEnabled() by GetDmaProtectionEnabledEngineMask(), for better code management.

V1:
This series patch adds Pre-Memory DMA protection in PEI. The purpose is to make sure when the system memory is initialized, the DMA protection takes effect immediately. The IntelVTdPmrPei driver is updated to remove the global variable and add VTD_INFO_PPI notification. The VTdInfoSample driver is updated to install the initial VTD_INFO_PPI before memory init, and add more content after memory init by reinstalling VTD_INFO_PPI. This patch is validated on one Intel Client kabylake platform.

For more info, see full patch:
https://lists.01.org/mailman/listinfo/edk2-devel

VisualUEFI udpated

https://github.com/ionescu007/VisualUefi

http://www.windows-internals.com/pages/training-services/windows-uefi-development/

Porting UEFI to Apple PowerPC…

Porting UEFI to a new architecture:
So it turns out that blogging about something after the fact is pretty tough. I really wanted to blog about my PoC port of UEFI to the OpenPower ecosystem, but it’s incredibly difficult to go back and try to systematize something that’s been a few years back. So let’s try this again. This time, our victim will be a G4 12″ PowerBook6,8 with a 7447A. That’s a 32-bit PowerPC. Now, I’ll go in small steps and document everything. For added fun, we’ll begin porting on the target itself, at least until that gets too tedious. Also, I’ve a few OldWorld machines, a spare G4 12″ for parts and a G5, so hopefully this odyssey won’t be interrupted by old and failing hardware ;-). Keep in mind that each part is checked in along with the source code, so look at the entire commit. Each blog post will focus on the most important details.[…]

http://osdevnotes.blogspot.com/2017/07/porting-uefi-to-xxx-step-1.html
https://github.com/andreiw/ppcnw-edk2
https://github.com/andreiw/ppcnw-edk2/blob/master/PortingHowTo_p1.md

See-also:
https://firmwaresecurity.com/2016/02/24/interview-with-andrei-warkentin-openpower-uefi-porter/
https://firmwaresecurity.com/2015/10/12/tianocore-for-openpower/

 

Alex updates smmtestbuildscript for Fedora 26 and QEMU 2.9

A while ago[1], Alex Floyd of PreOS Security wrote a shell script to help codify this wiki article[2] by Laslo Ersek of Red Hat, setting up a UEFI SMM/OVMF testing environment for Fedora-based systems. Recently, Alex updated this script to work with the recently-released Fedora 26. Quoting email from Alex on the changes in this release:

The build script has been updated for Fedora 26 support. It now uses the native QEMU 2.9 library from Fedora 26 and no longer builds a snapshot of QEMU 2.9 which makes some new testing possibilities available.

https://github.com/gencymex/smmtestbuildscript

[1] https://firmwaresecurity.com/2017/04/19/shell-script-for-laszlos-smm-test-environment-article/

[2] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt