This tool is an experiment to try to implement an EFI Byte Code Virtual Machine
Tag: UEFI
DiskImageCreator: designed to help people attack the machine with a secure chain-of-trust boot process in UEFI BIOS
[[
UPDATE: adding URL, which I forgot in original post:
https://github.com/tsunghowu/DiskImageCreator
]]
DiskImageCreator : A python utility to process the input raw disk image and sign MBR/partitions with given corresponding keys.
Signing Tool for boot security validation.
This python utility is designed to provide a baseline for people who may be interested in attaching the machine with secure boot process built-in. The secure boot process is a customized chain-of-trust boot flow in UEFI BIOS. It will exam the target disk image(in MBR) and see if it is properly signed by the root key controlled by owner. This utility is to help owner to create a signed image with owner keys.
This tool is designed to help people attack the machine with a secure chain-of-trust boot process in UEFI BIOS.
Update on Microsoft UEFI Github projects
Re: https://firmwaresecurity.com/2017/11/01/microsoft-uefi-capsule-update-package-on-github/
Last year at the UEFI Forum Spring Plugfest, Microsoft announced a new Github tree with UEFI-centric code.
This year, they talked about some new code on that tree.
Honestly, I thought that they haven’t been doing anything in a year, but it ends up all the activity has been in the BRANCHES:
https://github.com/Microsoft/MS_UEFI
For example:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport
So, there’s a lot of new Microosoft UEFI-related code on this tree, just not on the master. 🙂
CeLoader: A UEFI bootloader for Windows CE
CELoader is an EFI application that can load and boot to a Windows CE kernel (NK.EXE). The code is fairly simple but demonstrates the ability to read and write the console, read files and query and configure the graphics system. The loader configures the BootArgs structure with information needed by the kernel. Finally, the loader jumps to the entry point of the CE kernel.
UEFI tool: UEFI image parsing tools in Go language
UEFI tool: This repository will contain tools to parse and manipulate UEFI firmware images.
https://github.com/insomniacslk/uefi
Not to be confused with UEFITool, which is in C++, not Go.
Intel: Implementing MicroPython as a UEFI test framework
ARM Dynamic Tables Framework
ARM has submitted a patch to UEFI’s Tianocore which adds a “Dynamic Tables” framework that abstracts ACPI amongst other things… Readme excerpt of patch below:
This patch introduces a branch for implementing Dynamic Tables Framework.
To reduce the amount of effort required in porting firmware to new platforms, we propose this “Dynamic Tables” framework. The aim is to provide an example implementation capable of generating the firmware tables from an external source. This is potentially a management node, either local or remote, or, where suitable, a file that might be generated from the system construction. This initial “proof of concept” release does not fully implement that – the configuration is held in local UEFI modules.
The dynamic tables framework is designed to generate standardised firmware tables that describe the hardware information at run-time. A goal of standardised firmware is to have a common firmware for a platform capable of booting both Windows and Linux operating systems.
Traditionally the firmware tables are handcrafted using ACPI Source Language (ASL), Table Definition Language (TDL) and C-code. This approach can be error prone and involves time consuming debugging. In addition, it may be desirable to configure platform hardware at runtime such as: configuring the number of cores available for use by the OS, or turning SoC features ON or OFF.
The dynamic tables framework simplifies this by providing a set of standard table generators, that are implemented as libraries. These generators query a platform specific component, the ‘Configuration Manager’, to collate the information required for generating the tables at run-time.
The framework also provides the ability to implement custom/OEM generators; thereby facilitating support for custom tables. The custom generators can also utilize the existing standard generators and override any functionality if needed.
The framework currently implements a set of standard ACPI table generators for ARM architecture, that can generate Server Base Boot Requirement (SBBR) compliant tables. Although, the set of standard generators implement the functionality required for ARM architecture; the framework is extensible, and support for other architectures can be added easily.
The framework currently supports the following table generators for ARM:
* DBG2 – Debug Port Table 2
* DSDT – Differentiated system description table. This is essentially a RAW table generator.
* FADT – Fixed ACPI Description Table
* GTDT – Generic Timer Description Table
* IORT – IO Remapping Table
* MADT – Multiple APIC Description Table
* MCFG – PCI Express memory mapped configuration space base address Description Table
* SPCR – Serial Port Console Redirection Table
* SSDT – Secondary System Description Table. This is essentially a RAW table generator.
[…]Please create a branch called ‘dynamictables’ in edk2-staging.[…]
More info: see the “[PATCH] Branch to implement Dynamic Tables Framework” thread on the edk2-devel list by Sami Mujawar. And look for above branch to be created.
Hmm, it appears the links to the archives on the URL provided in the mailing list posts is not valid:
https://lists.01.org/mailman/listinfo/edk2-devel
V1 from Oct2017:
Finbarr’s UEFI-Utilities-2018
Finbarr Murphy has updated UEFI Utilities again. Earlier it was GNU-EFI based, now it is EDK2 based, and uses VS2018.
https://github.com/fpmurphy/UEFI-Utilities-2018
Maybe not finished migrating yet, but there are more tools in the older version than this, so don’t ignore the old tools.
https://github.com/fpmurphy/UEFI-Utilities-2016
And sometimes it seems the latest tools are only available the HTML of recent blob posts, so look there as well:
simple-bootsplash: displays the UEFI Logo during initramfs stage
simple-bootsplash
displays the UEFI Logo during initramfs stage
depends on fbv, xrandr, awk, lzop
UEFIoverclockMonitor.efi: Monitor TSC, default and overclocked CPU frequencies
Written in FASM.
Measure TSC, default and overclocked CPU frequencies.
https://github.com/manusov/UEFIoverclockMonitor
UEFI topics in Paul’s Security Weekly 550-551
Episode 550 has AMI, and 551 has Phoenix
https://securityweekly.com/subscribe/
https://wiki.securityweekly.com/Episode550
https://wiki.securityweekly.com/Episode551
Sorry can’t find URL to the 551 video, leaving that as ‘an exercise for the reader’. 🙂
https://securityweekly.com/subscribe/
OpenXT: adding anti-evil maid support, using UEFI and Xen in place of TXT
[…]In this PR OpenXT is extended to allow booting under UEFI while maintaining current security properties.,Changes to Measured Launch,,Booting OpenXT under UEFI introduces significant changes to the Measured Launch system of OpenXT by switching to the use of SRTM PCRs. Performing DRTM with TXT when booting under UEFI is not supported but can be implemented at a later date. OpenXT under UEFI relies on the shim EFI application to perform necessary measurements of critical boot components of OpenXT. OpenXT’s static PCR list is extended to include PCR4, PCR5, PCR7 and PCR8. Specific to OpenXT’s context, PCR4 holds the measurements of the shim, Xen and the dom0 kernel while PCR8 holds the measurements of openxt.cfg, the dom0 initrd image and the XSM policy. Any change in these components, selecting a boot entry other then the one used when Sealing took place and/or booting any application before the shim will result in the Measured Launch system tripping.[…]
https://github.com/OpenXT/xenclient-oe/pull/828
MicroPython for UEFI
https://twitter.com/DevZoneBlog/status/971860129946611712
[…]my team investigated several options to support Python 3.x in UEFI boot services. Because firmware is a constrained environment compared to OS runtime, we evaluated porting MicroPython to UEFI. MicroPython is a Python 3 variant designed for microcontrollers, with memory and size optimizations that make it ideal for pre-OS applications. […] Supporting Python 3.x & MicroPython in open source creates new opportunities for the TianoCore community to validate robust firmware solutions.[…]
https://software.intel.com/en-us/blogs/2018/03/08/implementing-micropython-as-a-uefi-test-framework
UefiDiskBenchmark.efi: Mass storage benchmark for UEFI (written in FASM)
UefiDiskBenchmark: Mass storage benchmark, based on EFI_BLOCK_IO_PROTOCOL EFI Byte Code (EBC) application.
Output parameters and flags:
“#” Device number in the list
“Revision” Revision of UEFI API EFI_BLOCK_IO_PROTOCOL.
“Media” Media ID
“RM” Removable Media flag, for example CD or USB flash
“MP” Media Present
“LP” Logical Partition
“RO” Read Only
“WC” Write Cache
“Block” Block size, bytes
“Align” Required alignment for memory buffer, bytes
“Size” Available size of mass storage device
Known bug: maximum 10 devices supported, include aliases.
https://github.com/manusov/UEFIdiskBenchmark
UefiUsbScan.efi: Scan USB host controllers and connections, written in FASM
UefiUsbScan: Scan for USB host controllers and connections, current version use direct PCI/MMIO hardware access. Only xHCI controllers supported yet, not supports UHCI, OHCI, EHCI.
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:
Kotlin-native-UEFI: A UEFI Application made by kotlin-native
It appears that there *might* be some Kotlin support for UEFI target. There is a new project that hints of this, but project is too new, no docs/comments, looks to not be ready for use yet.
https://github.com/youta1119/kotlin-native-uefi
I suspect this is part of the same person’s KotlinOS project:
https://github.com/youta1119/koslin-os
Richard Wilkins of Phoenix on UEFI-based IoT security (and rant on firmware diversity)
Richard Wilkins of Phoenix Technologies has an article in Embedded Computing about UEFI-based IoT security:
[…]This article is focused on system startup/firmware and the potential security problems for IoT devices in that space. And most important, what to do about them.[…]
http://www.embedded-computing.com/articles/firmware-security-for-iot-devices
PS: RANT… for some reason, one sentence jumped out at me:
“So why isn’t everyone using UEFI firmware? If the UEFI architecture provides the “solution” to these security threats, why isn’t everyone using it?”
I think the answer: UEFI is *A* solution, there are other solutions. Coreboot with Heads is another solution. Coreboot with Verified Boot is another solution. Using TXT and TPM measurements are other layers. Hypervisors/TEEs/SEEs are another layer. Separate security processors are another way. What is the right way, why isn’t everyone using one way? While I am a UEFI Forum member, I don’t think UEFI everyone should be using it. I welcome firmware diversity. 🙂 IMO, there are multiple implementations of signed code, signed updates, and a signed boot-up process, controlled by multiple (not a single) organization. I’m still hoping to see some professor gets a grad student to write a report doing a proper comparision of the various modern firmware security implementations’ strengths, so someone can start to make a reasonale decision as to which firmware security architecture is the solution for them.
UEFI Python: CPython 3.x or MicroPython 3.4?
In the beginning, Intel maintained CPython 2.x for UEFI. Current version is 2.7x. It looks like they may have stopped porting it, I am unclear.
In addition to Intel’s CPython 2.7x port, recently Google has proposed updating CPython 3.x to support UEFI, see:
I may’ve missed it, but I not sure Intel is involved with this effort.
At the UEFI Plugfest later this month, Intel is giving a talk about MicroPython for UEFI, “Implementing MicroPython in UEFI”. So I am *guessing* that Intel has chosen MicroPython over CPython. I presume this means that CPython 2.7x port is now abandonware. I hope the CPython 3.x proposal is not dead, because of this MicroPython effort. Hoping both get traction, but will not hold my breath…
https://micropython.org/
https://github.com/micropython/micropython
Differences between CPython and MicroPython:
http://docs.micropython.org/en/latest/pyboard/genrst/index.html
https://pypi.python.org/pypi?%3Aaction=search&term=micropython
Once once of these Python 3.x implementations works, and the CHIPSEC project ports from 2.x to 3.c, I can finally stop using v2!!
UEFI Forum Spring 2018 plugfest agenda
The UEFI Plugfest is in Seattle later this month.
I guess I missed the CFP, as the agenda is now available… 😦
* Intel: An Introduction to Platform Security
* Phoenix: TBD
* Arm:UEFI Updates, Secure Firmware and Secure Services on Arm
* Intel: The State of ASL Programming
* Intel: Implementing MicroPython in UEFI
* Insyde Software: UEFI and the Security Development Lifecycle
* Intel: Attacking and Defending the Platform
* Microsoft: Microsoft Security Features and Firmware Configurations
* Arm: Dynamic Tables Framework: A Step Towards Automatic Generation of ACPI & SMBIOS Tables
* Microsoft: Microsoft Sample Code on GitHub and Walkthrough on Firmware Updates and WU
* Linaro: Edk2-Platforms Overview
* AMI: Enabling Advanced NVMe Features Through UEFI
Firmware Security 
You must be logged in to post a comment.