Tag: UEFI

UEFIThreads: EFIDroid’s port of LittleKernel’s thread library for UEFI

~ hucktech ~ Leave a comment

UEFI is event-based, not thread-based. Earlier this month, Michael Zimmermann of the EFIDroid project posted a message on the EDK2-devel list about EFIDroid’s thread library support for UEFI, which is based on the Little Kernel threads implementation, and comparing it to the GreenThreads-UEFI project. Edited (footnotified) version of Michael’s message below.

IMO this [GreenThreads-UEFI] library[0] has some crucial problems like changing the TPL during context switching. For my project “EFIDroid” I’ve invested many months analyzing, testing and implementing my own threading implementation based on LK(LittleKernel, a MIT licensed project) threads and get/set -context. The result is a pretty stable implementation which can even be used in UEFI drivers[1]. I’m currently using this lib for my LKL(LinuxKernelLibrary) port to be able to use linux touchscreen drivers in UEFI – so you could say it has been well tested. The only “problem” is that it only supports ARM right now and that the get/set context implementation was copied (and simplified) from glibc which means that this part is GPL code.

From the Little Kernel web site:

Who is using LK?
* LK is the Android bootloader and is also used in Android Trusted Execution Environment – “Trusty TEE” Operating System.
* Newer Android phones have some chance of LK running all the time alongside Linux.
* A few ARM SoC manufacturers use LK as their default bootloader such as DragonBoard 410c based on Qualcomm Snapdragon 410 processor.
* The Fuchsia Operating System’s microkernel, Zircon is based on LK.

[0] https://github.com/Openwide-Ingenierie/GreenThreads-UEFI
[1] https://github.com/efidroid/uefi_edk2packages_EFIDroidLKLPkg/tree/master/UEFIThreads
http://efidroid.org/

https://github.com/littlekernel
https://github.com/littlekernel/lk/wiki/Introduction
https://github.com/littlekernel/lk/blob/master/kernel/thread.c

Click to access lm80-p0436-1_little_kernel_boot_loader_overview.pdf

https://android.googlesource.com/kernel/lk/

Full message: 2017-11-02 post on EDK2-devel.

Nick FitzGerald of ESET on scanning UEFI

~ hucktech ~ Leave a comment

ESET recently released a scanner for UEFI. Nick FitzGerald, ESET, Senior Research Fellow, has an article on why you should scan your UEFI firmware.

UEFI 101, and why you need it scanned
By Nick FitzGerald
Monday, November 20, 2017 – 15:16

In the rapidly evolving world of security software development, recent research has shown that UEFI scanning has transformed from a “nice to have” into a “must have” feature. Initially deemed a theoretical threat, there was little information about real-world UEFI attacks in the wild. However over time, enough data was collected and analyzed by cybersecurity vendors to conclude that UEFI protection is now required.[…]

https://www.networksasia.net/article/uefi-101-and-why-you-need-it-scanned.1511162171

 

Toms Hardware: Win10 unsupported disk layout UEFI error howto

~ hucktech ~ Leave a comment

Tom’s Hardware – an example of a computer review site that never shows CHIPSEC results 😦 — has a new article on how to fix a common UEFI/Windows problem:

How To Fix Windows 10 Unsupported Disk Layout UEFI Error
by Seth Colaner November 17, 2017 at 1:30 PM

A common problem that Windows users have encountered when trying to update Windows 10 is the “Unsupported Disk Layout for UEFI Firmware” error. This error basically means that the partition structure of your hard drive is not supported by the version of Windows 10 that you want to upgrade to. This error can be resolved by creating a Microsoft Reserved Partition (MSR), which is used on Unified Extensible Firmware Interface (UEFI)/GUID Partition Table (GPT) disks. Without getting too technical, we will outline the steps to fix this error when attempting to update.[…]

http://www.tomshardware.com/news/how-to-fix-windows-10-unsupported-disk-layout-uefi-error,35960.html

PS: Tom, please start showing CHIPSEC (and FWTS) results in your reviews, less on what colors the cases come in, and more on what security the HW/FW fails to offer. Thanks!

FWTS 17.11.00 released (and added to LUV)

~ hucktech ~ Leave a comment

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: mkpackage.sh: 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

https://launchpad.net/ubuntu/+source/fwts
http://fwts.ubuntu.com/release/fwts-V17.11.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/17.11.00

See full announcement for list of few-dozen bugfixes.

Full announcement:
https://lists.ubuntu.com/archives/fwts-announce

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

Update FWTS to version v17.11.00

Full patch:
https://lists.01.org/mailman/listinfo/luv

Kaspersky 2018 Threat Predictions: Sophisticated UEFI and BIOS attacks

~ hucktech ~ Leave a comment

Kaspersky Security Bulletin: Threat Predictions for 2018
Juan Andrés Guerrero-Saade, Costin Raiu, Kurt Baumgartner
[…]
Sophisticated UEFI and BIOS attacks.
The Unified Extensible Firmware Interface (UEFI) is a software interface which serves as the intermediary between the firmware and the operating system on modern PCs. Established in 2005 by an alliance of leading software and hardware developers, Intel most notable amongst them, it’s now quickly superseding the legacy BIOS standard. This was achieved thanks to a number of advanced features that BIOS lacks: for example, the ability to install and run executables, networking and Internet capabilities, cryptography, CPU-independent architecture and drivers, etc. The very advanced capabilities that make UEFI such an attractive platform also open the way to new vulnerabilities that didn’t exist in the age of the more rigid BIOS. For example, the ability to run custom executable modules makes it possible to create malware that would be launched by UEFI directly before any anti-malware solution – or, indeed, the OS itself – had a chance to start. The fact that commercial-grade UEFI malware exists has been known since 2015, when the Hacking team UEFI modules were discovered. With that in mind, it is perhaps surprising that no significant UEFI malware has been found, a fact that we attribute to the difficulty in detecting these in a reliable way. We estimate that in 2018 we will see the discovery of more UEFI-based malware.[…]

Kaspersky Security Bulletin: Threat Predictions for 2018

Click to access KSB_Predictions_2018_eng.pdf

Predictions for 2018: Cyberthreats in the financial sector

Fall UEFI plugfest presentations uploaded

~ hucktech ~ Leave a comment

Fall 2017 UEFI Plugfest – October 30-November 3, 2017

State of the UEFI – Mark Doran (UEFI Forum President)
UEFI Security Response Team (USRT) – Dick Wilkins (UEFI Forum)
“Last Mile” Barriers to Removing Legacy BIOS – Brian Richardson (Intel)
UEFI Firmware Security Concerns and Best Practices – Dick Wilkins (Phoenix)
Strategies for Stronger Software SMI Security in UEFI Firmware – Tim Lewis (Insyde)
UEFI in Arm Platform Architecture – Dong Wei (ARM)
Self-Certification Tests (SCTs) in UEFI World – Eric Jin (Intel) and Alex Hung (Canonical)
Firmware Test Suite -Uses, Development, Contribution and GPL – Alex Hung (Canonical)
Near Field Communication (NFC) and UEFI – Tony Lo (AMI)
EDK2 Platforms Overview – Leif Lindholm (Linaro)
UEFI Manageability and REST Services – Abner Chang (HPE) and Ting Ye (Intel)

http://www.uefi.org/learning_center/presentationsandvideos

Restart2UEFI: restart UEFI systems to firmware (for Windows)

~ hucktech ~ Leave a comment

This is a new project, a C# GUI that requires Windows and Visual Studio to build. It appears to be a wrapper to the Windows shutdown.exe utility.

https://github.com/spoonieau/Restart2UEFI

Restart2UEFI: Utility’s to restart uefi systems to firmware. An easyer way to get your system to boot to the motherboards firmware interface than going Win’s recovery options, to finding a pappercilp the certain notebooks.

Restart2UEFI winforms build ported to UWP. Needs Restart2UEFIHelper.exe in projects win32 dir. Was going to be release on the windows store but due to needing the use of a win32exe and only holding a developer licence. So I was unable to submit and have a compiled App available.

 

UEFI-Bootkit docs updated

~ hucktech ~ Leave a comment

Re: https://firmwaresecurity.com/2016/11/04/uefi-bootkit/

Aidan Khoury of Quarkslab has updated UEFI-Bootkit. Only change to the project in the last year was update to readme, with more info. It is worth reading the USRT review of this bootkit, in the above URL.

https://github.com/dude719/UEFI-Bootkit

UEFI-Bootkit: A small bootkit designed to use zero assembly. Make sure to compile the driver as an EFI Runtime driver (EFI_RUNTIME_DRIVER) or else the bootkit will be freed once winload.efi calls ExitBootServices! Thanks to pyro666, dreamboot, and VisualUEFI.

alt text

 

xen-uefi: Instructions and tools to boot Xen in UEFI mode with TPM measurements of Xen and dom0

~ hucktech ~ Leave a comment

Instructions and tools to boot Xen in UEFI mode with TPM measurements of Xen and dom0

This repository contains tools and instructions for installing Xen and dom0 with UEFI/SecureBoot such that all critical components of Xen and the dom0 kernel get SecureBoot verified and measured into the TPM.

https://github.com/tklengyel/xen-uefi

Includes an updated Shim.

Proposal for CPython v3.x for UEFI

~ hucktech ~ 1 Comment

Thiebaud Weksteen of Google posted a message on the UEFI Forum EDK2 and Python development lists, asking for help with an official port of Python for UEFI. Please help out if you can!! Excerpt of his message below, full message (and thread):
https://lists.01.org/pipermail/edk2-devel/2017-November/016805.html

UEFI has become the standard for firmware (BIOS) interface. Intel has provided an open source implementation under the name EDK2 (part of the TianoCore initiative) [1] for some time. This implementation has evolved significantly and now provides the functionalities of a small OS with a standard library similar to POSIX. In 2011, a port of Python 2.7.1 was added to the EDK2 repository [2]. This port then evolved to 2.7.2 which is still defined as the reference port [3]. In 2015, another port was added of Python 2.7.10 in parallel of 2.7.2 [4]. Since then, both implementations have diverged from upstream and know vulnerabilities have not been fixed. I would like to bring support for edk2 in the official Python repository to remediate this situation, that is officially support edk2 as a platform. Technically, there would be three main aspects for the on-boarding work:

1) Fix headers and source to resolve definition conflicts, similarly to ABS definition in [5];
2) Add the edk2module.c [6] to handle platform-specific functionalities, similarly to the posixmodule.c;
3) Add the build configuration file [7] and necessary modifications within Python to handle the edk2 toolchain;

This work would target the master branch (that is Python 3). I would be interested in hearing your thoughts on this idea.

[1] https://github.com/tianocore/edk2
[2] https://github.com/tianocore/edk2/commit/006fecd5a177b4b7b6b36fab6690bf2b2fa11829
[3] https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/PythonReadMe.txt
[4] https://github.com/tianocore/edk2/commit/c8042e10763bca064df257547d04ae3dfcdfaf91
[5] https://gist.github.com/tweksteen/ed516ca7ab7dfa8d18428f59d9c22a3e
[6] https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/Efi/edk2module.c
[7] https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/PythonCore.inf

 

Insyde Software security updates for Windows 10

~ hucktech ~ Leave a comment

Hurray, UEFI vendors focusing on security! 🙂

Insyde® Software Highlights Strategies to Strengthen Firmware Security at the Fall UEFI Plugfest

Company’s Chief Technology Officer to Present at The UEFI Forum Plugfest in Taipei, Taiwan

[…]In related UEFI-security news, Insyde Software announced its full compliance with the latest firmware security updates needed by Microsoft’s upcoming Windows® release. The Windows 10 Fall Creators Update adds new requirements that include improved support for TPMs (Trusted Platform Modules) and new functionality for Secure Boot BIOS update, all of which is fully supported by InsydeH2O® UEFI BIOS.[…]

https://www.insyde.com/press_news/press-releases/insyde%C2%AE-software-highlights-strategies-strengthen-firmware-security-fall

Fall UEFI Plugfest agenda

~ hucktech ~ Leave a comment

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.