bootloader_instrumentation_suite – Bootloader research tools (very much a work in progress)
This test suite helps you keep track of different versions of
u-boot/build tools, static analysis of that build’s binaries, and
runtime trace results of running that binary on a given hardware
configuration. For each u-boot/build configuration it keeps a database
of information it statically gathered for each boot stage, boot stage
images/ELF files, a prepared SD card image, and test results of
runtime trace analyses. If it detects changes in the u-boot source or
build tools it will create a new set of test result directories with a
new sdcard image and static analysis results.
There is a new Redfish command line tool being worked on (just getting started, not ready for use yet):
Erik Orejuela and Julio Franco have a new article on TechSpot, discussing BIOS vendor tools, covering these vendors’ tools:
Asus Live Update
MSI Live Update
ASRock Live Update
Biostar BIOS Update Utility
Ugh, their web page has some obnoxious code that changes the HTML header every few seconds to try and get your attention.
LinuxFestNorthWest was last weekend in Washington State. For the first time, there was an “Open Source Firmware” track, search for that string on the event listings for those presentations:
The LFNW videos are already up on Youtube:
I am still working on uploading my slides to the LFNW web site, and Github, please give me another day to find my password… 😦
From a March 2018 Dell blog post:
[…]Our latest contribution to the open source community is related to our work on Redfish. It is RedDrum, an open source, python-based implementation of a Redfish service, and includes a recipe for backend integration with OpenBMC. RedDrum allows client system management software to use standard Redfish APIs to access the capabilities provided by OpenBMC. RedDrum is derived from the currently shipping Dell EMC DSS 9000 Rack Manager Redfish service and shows our continued leadership and commitment to improve developer and interoperability tools to enable the Redfish eco-system. Our open source RedDrum contribution includes two important components: A high-fidelity Redfish Service Simulator for developers, and Integration with a real OpenBMC platform (Power9 server). Both the simulator implementation and the platform integration implementation are structured with a “front-end” protocol engine and a “back-end” for data gathering/processing. The front-end protocol engine for both is exactly the same, but the back-end capabilities are what distinguish them.[…]
u-bmc is a Linux OS distribution that is fully open-source for baseboard management controllers, or BMCs. u-bmc uses u-root to create a Linux OS distribution that is fully open-source. u-bmc borrows and contributes to OpenBMC which has similar high-level goals. The main difference is that u-bmc chooses to challenge the industry status quo. E.g. where OpenBMC uses IPMI, u-bmc uses gRPC. […] Historically BMCs have been considered insecure by nature and have received little to no attention – not unlike BIOSes. While LinuxBoot’s mission is to uplift BIOS firmware for existing servers, u-bmc’s is to uplift BMC firmware. The implementations differ, some things are shared, but the goal is the same. u-bmc, like LinuxBoot, sacrifices classical industry compatibility in order to offer a solution that is genuinely tailored for the mission. By close collaboration between LinuxBoot and u-bmc, the hope is to one day have servers that ship with both free and open BMC as well as BIOS.
I thought OpenBMC was the only attempt at BMC library implementation. There’s also bmclib from the BMC-Toolbox project, by Booking.com.
- bmcldap: A LDAP proxy to authenticate BMCs
- bmcbutler: BMC configuration management tool
- bmclogin: A small helper library to login to BMCs.
- dora: Tool to discover, collect data from multiple types of Servers and Chassis BMCs
- actor: Api to carry out actions to BMCs
- gin-go-metrics: gin-gonic/gin middleware to gather and store metrics using rcrowley/go-metrics
- bmclib: Library to interact with bmcs from different vendors
- redgopher: An attempt to generate a redfish 2018.3 openAPI client
- bmcfwupd: BMC firmware management tool
There was a talk about bmclib at the last FOSDEM:
This talk is about bmclib, a library written to perform asset lifecycle management, across a fleet of bare metal servers, it leverages existing (mostly undocumented) APIs on Baseboard Management Controllers, and exposes a consistent API interface to: Inventorize bare metal hardware, Manage BMC/BIOS configuration, Reliably Power cycle/PXE boot bare metal, Update firmware on BMCs. […]
This blog is part three in a four-part series on hardware hacking for the security professional and researcher. Be sure to check out part one, which covers Atmel microcontrollers, and part two, which discusses Nordic RF microcontrollers. In this blog, we will conduct further firmware extraction exercises and cover the Microchip PIC microcontroller (PIC32MX695F512H). To be able to gain access to the firmware on PIC microcontrollers, we will need to read directly from the controller over the in-circuit serial programmer (ICSP).[…]
Maddie Stone has published her Intro to Android App RE workshop! There is a VM on the Github project.
Intel will be speaking at Blackhat about Intel ME!
Like Bloomberg’s SuperMicro claims, I don’t see any evidence/proof yet…
Dear (UEFI Forum, Trustworthy Computing Group, Intel):
For my birthday, I’d like to have a spreadsheet showing which Linux distributions support Trusted Boot, Measured Boot, and/or Secure Boot, and if it supports FWUpd.
For Secure Boot, the UEFI Certificate Authority has the data, but they’re not showing the list of signed bootloaders.
For the certs, it’d be useful to know WHO signed it. The default UEFI CA (Microsoft) may be the sign, but some distros will go another route.
I’d like to know if their Secure Boot key is up-to-date. Today I’d have to access the dbx blacklist tool. On Redhat, I could use dbxtool. On other distros, no tool to help AFAIK. Again, the UEFI CA would have this data, and could put it in a human-readable spreadsheet, the DBX blacklist file hosted in uefi.org is not human-readable. There should be pointers to their keys and how to test them, something to replace lack of CRL/OSCP for firmware certs.
Extra points if you can clarify how well the distro supports Secure Boot. When enabled, Fedora won’t let unsigned kernel drivers load, but Ubuntu will only disable unsigned drivers during the boot process but will run them post-boot. So, security-minded users would want to use Fedora instead of Ubuntu, until Ubuntu fixes this security hole.
Today, the only way I know how to get a clue if a distro may support Secure Boot is by checking:
It would probably be nice to include ALL operating systems, not just Linux distros. FreeBSD now has some Secure Boot support.
It would also be nice to note which booloader the distro uses (eg, GRUB2, rEFInd, or something else.)
FWUpd support data is, at least, publicly-available.
Thanking you in advance! 🙂
This 2017 document has been updated this month.
OpenPOWER secure and trusted boot, Part 1: Using trusted boot on IBM OpenPOWER servers: Making your system safe against boot code cyberattacks
by Dave Heller, Tim Block
Updated April 26, 2019 – Published February 17, 2017
OpenPOWER servers provide a firmware-level security facility known as Trusted Boot. Trusted Boot helps you to verify that your server is running only authorized firmware components from IBM or another trusted vendor. This allows you to detect and take corrective action in case of a boot code cyberattack – that is, any attempt to replace your trusted firmware with malicious code. If an attacker can inject malicious code at the firmware level, no amount of protection within the operating system can prevent the attacker from gaining control of your server.
This repo contains some UEFI learning documents collected by individuals. Although these documents are not comprehensive enough, they are still helpful for beginner developers.
Their web site of the above Github markdown is apparently down (at least for me):
Unicycle is a bare-metal OS, and bootloader is UEFI bootloader that runs the apps.
UEFI-based bootloader for Unicycle applications: UEFI bootloader that allows to load Unicycle application directly, without any support from operating system like Linux. This bootloader implements Uniboot protocol on top of UEFI specification. The bootloader supports booting from the same bootable device where bootloader.efi is located or loading from network using TFTP protocol.
Unicycle – unikernel application framework: Most modern day operating systems use idea of separating applications from kernel. Kernel has access to underlying hardware and resources. If some application needs access to the hardware (like network or disk) then it asks kernel to perform the action. Such separation to kernel vs userspace became dominant in 60s when computers were expensive and need to be shared between large number of users. And it works well for majority of use-cases. Though performing a context switch between userspace and kernel to make an action is not free. Heavy-loaded applications that need to make a large number of input/output operations spend quite a lot of time switching back and forth. But what if the application code lived in the kernel address space and thus the context switch can be avoided altogther? What if the application itself will take responsibilities on managing hardware directly? That is the main idea behind unikernel applications. And Unicycle project is a framework to create such applications. […]
This blog post isn’t meant to be a definitive guide about Secure Boot in Debian. The idea is to give some context about the boot sequence on the PC architecture, about the Secure Boot technology, and about some implementation details in Debian.[…]