There are multiple OS-level drivers which provide interfaces to UEFI via device drivers. CHIPSEC has one (actually 3), for Mac, Windows, and Linux. FWTS has one for Linux. Each UEFI-aware OS has their own driver-level code to interact with UEFI, some of them expose an API/DDI. Below are 3 other UEFI drivers. A secure OS should be checking for any drivers who interact with firmware, and have a user policy for optionally preventing this. Do you know all the tools and drivers in your OS which interacts with firmware?

Efi-memory: Efi-memory is a proof-of-concept EFI runtime driver for reading and writing to virtual memory. It uses EfiGuards method of hooking SetVariable to communicate with the user-mode process.

https://github.com/SamuelTulach/efi-memory

EfiDump: Yet another PoC EFI runtime driver. This time for direct process memory read/write. This is a simple example of how can process dumper work. If you want to use this for some more complex project, please add memory checks (or you are going to be bluescreening every 5 minutes) and save the Windows kernel exports pointers in the driver once, so you don’t have to send them every time.

https://github.com/SamuelTulach/EfiDump

EFI_Driver_Access: Efi Driver Access is a simply project to load a driver during system boot with the idea to give the user kernel access for read/write memory without restrictions.

https://github.com/TheCruZ/EFI_Driver_Access

Coming this Fall to a bookstore near you:

https://www.apress.com/gp/book/9781484261057

There are 3 versions, IPython/Jypter-style for Bash, PowerShell, or Python.

[…]providing the instructions and the response form for the HPE Discover Virtual Experience Hack Shack Redfish Challenge[…]DMTF’s Redfish is a standard designed to deliver simple and secure management for converged, hybrid IT and the Software-Defined Data Center (SDDC). Today it is rapidly replacing proprietary protocols. In this hands-on workshop, you’ll get to explore the Redfish tree of an OpenBMC and HPE iLO 5 to understand its basic structure, and learn how to modify resources and perform simple actions. You’ll interact with the HTTP/JSON-based standard using your favorite language, whether it’s PowerShell, Python or Bash/cURL. Beginners and experts welcome. Login to My Agenda above and Reserve or Waitlist session to notify us of your interest. Please note, this session will take place in Zoom and we will email you joining instructions.

user=”student”
Password = “P@ssw0rd!”

https://github.com/HPEDevCom/RedfishChallenge

https://hackshack.hpedev.io/

https://content.attend.hpe.com/go/agendabuilder.sessions/?l=1043&sid=20482_0&locale=en_US

Raytheon sells a few products with different firmware security features: Trusted Boot, Secure Boot, and Measured Boot. Their EA-TB whitepaper was just revised, ACAICT.

EA-TB offers an integral solution for cyber resiliency and technology protection. The EA Trusted Boot Solution EA-TB is a hardware-based foundation for ensuring secure boot and runtime integrity for commercial off-the-shelf (COTS) processors such as Intel-, ARM- and PowerPC-based systems. EA-TB defends against boot-level attacks and kernel/application modification, and protects against attackers gaining persistence on a system. It can also be deployed with Electronic Armor Operating System (EA-OS).[…]

Warning: first URL is a PDF which includes SPACEs in the filename. Ugh. Why didn’t W3C do more to discourage this sort of behavior?

Click to access 4500615_RIS_Electronic%20Armor%20Trusted%20Boot_v13.pdf

https://www.raytheonintelligenceandspace.com/capabilities/products/electronic-armor
https://www.raytheonintelligenceandspace.com/news/feature/get-bus

see-also: Boot Shield
https://www.raytheonintelligenceandspace.com/capabilities/products/boot-shield
https://www.raytheonintelligenceandspace.com/news/feature/fighting-hardware-hack

also-see-also: CounterVail
https://www.raytheonintelligenceandspace.com/capabilities/products/countervail

Have you ever wondered about the process a machine goes through to get to the point of a usable system? This post will give an overview of how machines boot and how this matters to QEMU. We will discuss firmware and BIOSes and the things they do before the OS kernel is loaded and your usable system is finally ready.[…]

https://www.qemu.org/2020/07/03/anatomy-of-a-boot/

This is a nice introduction to how people hack ACPI to get macOS working on non-Mac systems (Hackintosh). Includes breakdown of how various hardware components (CPU, EC, I2C, USB, IRQ, etc.) between different Intel processor revisions.

So what are DSDTs and SSDTs? Well, these are tables present in your firmware that outline hardware devices like USB controllers, CPU threads, embedded controllers, system clocks and such. A DSDT(Differentiated System Description Table) can be seen as the body holding most of the info with smaller bits of info being passed by the SSDT(Secondary System Description Table).[…]

https://github.com/dortania/Getting-Started-With-ACPI

[…]Security begins with the modular components of the system. The first requirement for a secure module is a secure boot. No unauthorized party should be able to tamper with the software while the processor is starting up—something that cannot just be bolted on. A secure boot starts with an initial phase loaded from on-chip masked ROM, so it must be built into the microprocessor silicon. Numerical cryptokeys that authenticate, decrypt, load, and start additional levels of encrypted software are stored in this secure memory. A secure ICS must be able to start up and to decay in a secure state. Intentional or unintentional power cycling must not degrade the level of cyber protection and cybersecurity. A secure boot of every system-wide microprocessor is essential to meeting this requirement.[…]

https://blog.isa.org/industrial-control-system-cybersecurity-build-bolt

I am not sure, but I think this Apple support document was created or updated in the last few days.

This article contains references for key product certifications, cryptographic validations, and security guidance for the Secure Enclave Processor (SEP): Secure Key Store. In addition to the general certificates listed here, other certificates may have been issued in order to demonstrate specific security requirements for some markets.[…]

https://support.apple.com/en-ph/HT209632

I am not sure, but this might be something interesting:

Potential new signing strategies ( for example signing grub, fwupdate and vmlinuz with separate certificates ) require shim to support a vendor provided bundle of trusted certificates and hashes, which allows shim to “whitelist” EFI binaries matching either certificate by signature, or hash in the vendor_db. Functionality is similar to vendor_dbx ( vendor blacklist ).

https://github.com/rhboot/shim/commit/bd89dabf5fc767e3824fd8b9e94b044cdb578fb1

There are probably many other more interesting checkins to this important codebase:

https://github.com/rhboot/shim/commits/master

This Insyde-specific Linux driver has been around for a year:

This is version 0.0.05 of the (GPLv2 licensed) Linux driver required to carry out firmware upgrades on Insyde Softwares UEFI platform, using the H2OFFT-L(x64) utility on GNU Linux. The utility itself is not available here, since it does not seem to be GPL licensed.[…]

There’ve been two sets of checkings: the initial one last year, and a single comment a few minutes ago:

No maintenance: Please note that I (@tomreyn, you may be looking at a fork of the original repo where things may differ) have no intention of maintaining this code. I’m merely making it available here on GitHub for others to fork and hack on it, just in case it goes offline at the original location I copied this GPLv2 code from.[…]

https://github.com/tomreyn/isfl/

If there was info on this on Insyde’s web site, I missed it. But there is this:

https://help.ubuntu.com/community/FimwareUpgrade/Insyde

[…]The HydraBus+HydraNFC Shield v2(hardware[1]) with HydraFW[2] (firmware) are used as an open source multi-tool for anyone interested in Learning/Developping/Debugging/Hacking/Penetration Testing for basic or advanced NFC communications.[…]

[1] https://hydrabus.com/hydranfc-shield-v2-specifications/
[2] https://github.com/hydrabus/hydrafw_hydranfc_shield_v2

 

There are Vagrant/bash scripts to help install half a dozen firmware analysis tools (binwalk, firmadyne, binaryanalysis-ng, firmware-mod-kit, firmwalker, etc.), which is helpful because most security tool authors are not good at writing installers.

https://github.com/jamesooo/binary-exploitation-lab

Includes updated Redfish support, as well as some changes after security audits.

https://lists.ozlabs.org/pipermail/openbmc/2020-July/022211.html
https://github.com/openbmc/docs/blob/master/release/release-notes.md
https://github.com/openbmc/openbmc/releases/tag/2.8.0

 

Re: https://firmwaresecurity.com/2015/08/28/new-efi-based-operating-systems/

Below is a list of currently-actively “UEFI hobby operating system”-style projects on Github, defining “active” as updated in last 2 months. Projects which haven’t been updated recently are not listed, but there are a few dozen other projects between above link and below list. Most are barely more than a hello-world bootloader; others are nearly-complete operating systems, some in C a few in Rust, I think one was in C#. List not sorted in any order:

https://github.com/vvaltchev/tilck
https://github.com/Michael-Kelley/RoseOS
https://github.com/GreenteaOS/Tofita
https://github.com/ondralukes/OndrOS
https://github.com/MCJack123/craftos-efi
https://github.com/Totsugekitai/minOSv2
https://github.com/portasynthinca3/neutron
https://github.com/wordandahalf/Stelox
https://github.com/kazuminn/minos
https://github.com/hikalium/liumos
https://github.com/sonjt0705/afwj-uefi
https://github.com/justinian/jsix
https://github.com/VerdureOS/Verdure
https://github.com/bSchnepp/Feral
https://github.com/DylanGTech/PiousOS
https://github.com/Lan-t/MyOsLoader
https://github.com/Ocean-git-hub/EgoisticOS
https://github.com/approvers/minimos

By Alejandro Mera, Bo Feng, Long Lu, Engin Kirda, William Robertson

[…]We present DICE, a drop-in solution for firmware analyzers to emulate DMA input channels and generate or manipulate DMA inputs. DICE is designed to be hardware-independent, and compatible with common MCU firmware and embedded architectures. DICE identifies DMA input channels as the firmware writes the source and destination DMA transfer pointers into the DMA controller. Then DICE manipulates the input transferred through DMA on behalf of the firmware analyzer. […]All our source code and dataset are publicly available.

https://arxiv.org/abs/2007.01502

PS: If someone can find the source code, leave the URL in a Comment, please.

Features:
* Find known EFI GUID’s
* Identified protocols which are finding with LOCATE_PROTOCOL function
* Identified functions used as the NOTIFY function
* Identified protocols installed in the module through INSTALL_PROTOCOL_INTERFACE
* Identified functions used as an interrupt function (like some hardware, software or child interrupt)
* Script for loading efi modules to relevant directories upon import in Headless mode
* Sorting smm modules relying on meta information by next folders[…]

https://github.com/DSecurity/efiSeek

 

Welcome to 2020.

It appears the Intel LUV (Linux UEFI Validation) distribution is no longer active. Last checkin:

The LUV project is not being maintained actively. Update the README accordingly.

https://github.com/intel/luv-yocto/commit/10bda4cf7d64cd36cd282463a5e2b5a536139fe9

https://01.org/linux-uefi-validation

https://github.com/intel/luv-yocto

Binary analysis is imperative for protecting COTS (common off-the-shelf) programs and analyzing and defending against the myriad of malicious code, where source code is unavailable, and the binary may even be obfuscated. Also, binary analysis provides the ground truth about program behavior since computers execute binaries (executables), not source code. However, binary analysis is challenging due to the lack of higher-level semantics. Many higher level techniques are often inadequate for analyzing even benign binaries, let alone potentially malicious binaries. Thus, we need to develop tools and techniques which work at the binary level, can be used for analyzing COTS software, as well as malicious binaries. One of the most challenging problems in the binary analysis is firmware analysis because of the given inter-dependencies between modules and pipelines inside the device, in most cases, it’s almost impossible to take the binary out of its environment and perform fuzzing on the binary individually. So, dynamic testing or fuzzing of embedded firmware is severely limited by the hardware-dependence and poor scalability, partly contributing to the widespread vulnerable IoT devices. Over the years, researchers found ways around this shortcoming by either emulating the I/O communication of peripherals to perform off-device fuzzing or using some tricks to perform on-the-device fuzzing. In this talk, I’ll cover the state-of-the-art for the firmware fuzzing by going through the history and the evolution of techniques that have been proposed so far and then I’ll go through another idea to perform fuzzing of IoT devices in large scale.

https://www.isi.edu/events/calendar/12822

Customize Secure Boot
The goal is to have you own certificate in the Secure Boot db variable.
Then, to sign Linux with your own certificate.
As we have dual boot with Windows, we’ll keep Microsoft and PC manufacturer certificates.

https://github.com/sebmillet/custom-uefi

Summary:
Detect Boot Mode Is Bios Or UEFI

https://github.com/czytcn/SystemUnityLib

Maybe it’s just me, but it seems a bit scary to think that games need to know about what kind of platform firmware they are booting from. 🙂