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:

https://www.linuxfestnorthwest.org/conferences/2019/schedule/events

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.[…]

https://github.com/RedDrum-Redfish-Project

https://www.dell.com/support/article/us/en/19/sln313941/extreme-scale-infrastructure-esi-architects-pov-series-dell-emc-contributes-open-source-redfish-service?lang=en

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.

https://github.com/u-root/u-bmc

https://u-bmc.readthedocs.io/en/latest/

https://asciinema.org/a/202889

I thought OpenBMC was the only attempt at BMC library implementation. There’s also bmclib from the BMC-Toolbox project, by Booking.com.

BMC-Toolbox projects:

• 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. […]

https://github.com/bmc-toolbox/bmclib

https://fosdem.org/2019/schedule/event/baseboard_management/

Click to access bmclib.pdf

Part 3 of my blog series on extracting firmware from MCUs was posted today @rapid7. Please check it out: https://t.co/AgShX0oQTQ

— Deral Heiland (@Percent_X) April 30, 2019

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).[…]

https://blog.rapid7.com/2019/04/30/extracting-firmware-from-microcontrollers-onboard-flash-memory-part-3-microchip-pic-microcontrollers/

https://blog.rapid7.com/2019/04/23/extracting-firmware-from-microcontrollers-onboard-flash-memory-part-2-nordic-rf-microcontrollers/

https://blog.rapid7.com/2019/04/16/extracting-firmware-from-microcontrollers-onboard-flash-memory-part-1-atmel-microcontrollers/

It's finally here! I have published my Intro to Android App Reverse Engineering workshop! If you're interested in learning how to begin RE'ing Android apps (both DEX and native code), check out this workshop. #reverseengineering #android #infosechttps://t.co/8h2WjfM2T1 pic.twitter.com/swFZc3tMCO

— Maddie Stone (@maddiestone) April 29, 2019

Maddie Stone has published her Intro to Android App RE workshop! There is a VM on the Github project.

https://maddiestone.github.io/AndroidAppRE/

https://github.com/maddiestone/AndroidAppRE

Go behind-the-scenes of Intel Security and learn how Intel CSME FW is mitigating security challenges by applying industry standards mitigation tailored to the FW environment and much more at this #BHUSA Briefing. https://t.co/EPSBNQ565S

— Black Hat (@BlackHatEvents) April 29, 2019

Intel will be speaking at Blackhat about Intel ME!

https://www.blackhat.com/us-19/briefings/schedule/index.html#behind-the-scenes-of-intel-security-and-manageability-engine-15789

Vodafone reveals hidden backdoors in Huawei equipment that could have made its fixed-line network in Italy vulnerable https://t.co/qmDo2TC9Xp

— Bloomberg (@business) April 30, 2019

Like Bloomberg’s SuperMicro claims, I don’t see any evidence/proof yet…

https://www.bloomberg.com/news/articles/2019-04-30/vodafone-found-hidden-backdoors-in-huawei-equipment

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:

https://distrowatch.com/search.php?pkg=shim&relation=lessequal&pkgver=1&distrorange=InAny

https://distrowatch.com/search.php?pkg=efibootmgr&pkgver=0.&distrorange=InLatest#pkgsearch

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.

https://developer.ibm.com/articles/trusted-boot-openpower/

This repo contains some UEFI learning documents collected by individuals. Although these documents are not comprehensive enough, they are still helpful for beginner developers.

https://github.com/xiaopangzi313/uefi_specs_personal_collections

See-also:
https://github.com/uefitech/resources

Their web site of the above Github markdown is apparently down (at least for me):

http://www.uefi.tech/

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.

https://github.com/libunicycle/bootloader

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. […]

https://github.com/libunicycle/unicycle

Two new projects on Github, baremetal hello-world apps written in assembler, one in NASM one in FASM.

https://github.com/charlesap/nasm-uefi

https://github.com/charlesap/fasm-uefi

An Overview of Secure Boot in Debian https://t.co/gEaTbrW9l4

— ladore (@ladore) April 28, 2019

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.[…]

https://debamax.com/blog/2019/04/19/an-overview-of-secure-boot-in-debian/

https://twitter.com/cruzhams/status/1121803167950417920

https://github.com/snovvcrash/usbrip

"Slides" for my AMD Talk:https://t.co/Aemt4iV75L

Text version:
HTML: https://t.co/wD7VDANYlZ
PDF (graphviz broken): https://t.co/Wz2BLOEfut

— Mimoja (◕ᴗ◕🌸🏳️‍🌈) (mimoja@chaos.social) (@WingsOfMimoja) April 26, 2019

https://chaos.mimoja.de/p/BkzDbBgsV#/

http://build.mimoja.de/AMD%20x86_64%20Firmware.html

[…]

Responsible for discovering and exploiting vulnerabilities affecting Dell software and firmware.
Developing and maintaining tools to assist in vulnerability research and exploit development.

[…]

https://jobs.dell.com/job/-/-/375/9088745

Kaspersky has a new blog post about the ASUS incident:

Operation ShadowHammer: a high-profile supply chain attack

Our full analysis of #shadowhammer and related gaming companies attacks, including a new (2018) variant of the #ShadowPad backdoor: https://t.co/DHR7UAg0uS

— Costin Raiu (@craiu) April 23, 2019

Google has a new blog post about Javascript and Spectre:

👻 A year with Spectre: a V8 perspective
 
In which the V8 team details their analysis and mitigation strategy for Spectre, one of the top computer security issues of 2018.
 https://t.co/jQ7R04XRbH

— V8 (@v8js) April 23, 2019

https://v8.dev/blog/spectre

NCC Group has some new research on TrustZone:

TECHNICAL ADVISORY: Private Key Extraction from #Qualcomm Hardware-backed Keystores. Read more: https://t.co/xFBXJSJnA9 @inf_0_ pic.twitter.com/cA8L4S1Mai

— NCC Group North America InfoSec (@NCCsecurityUS) April 23, 2019