Opening Event OSFC 2020
The Linux Vendor Firmware Service is a webapp used by OEMs, ODMs and ISVs to distribute firmware updates safely and securely to millions of Linux users. In this talk I will give a quick overview of what the LVFS actually is, the extra services it provides and describe the ways the Linux client communicates with the server. I’ll explain how the LVFS is essential for OEMs and why ignoring the LVFS and Linux users is short-sighted from a technical and business point of view.
In the talk I’ll show lots of pictures and graphs, which will make some vendors feel good, and make other vendors feel bad. I’ll include lots of technical details that might be interesting to OEMs and Linux users who are deploying firmware updates at scale.
During the talk I’ll also hint at a future specification we’re working on, designed to raise the level of firmware security across the entire ecosystem. The talk will finish with a look to the future.
The UEFI specification is both extensive and intricate. Development of firmware against the specification would not be possible without automated test tools. This talk covers the experience with UEFI SCT and the FirmWare Test Suite as well as the continuous integration testing for U-Boot. The remaining white areas are highlighted.
In today's smart computing platforms, a thermal management solution needs to be reliable and sustainable on various set of devices like 2-in-1s or tablets, client or edge and even on IOT devices. This presentation talks about the thermal management code flow in coreboot firmware for Intel SoC-based Chrome systems and the major thermal code clean, in which years of technical debt was cleaned up. In addition, coreboot introduced a new DPTF driver which replaces the static ASL policy files and generates SSDT-based thermal policy table at runtime. This eases the enablement and tuning processes for thermal policies to ensure the best end-user experience on the system.
Configuring all of the pieces for UEFI Secure Boot, generating keys in hardware tokens, signing kernels, integrating LUKS disk encryption with the TPM, and remotely attesting to the state of the system is very complex, yet vital part of locking down laptops and servers against adversaries. Users and administrators need a tool that wraps up all of the complexity into the few operations that they need from day to day: signing new kernels, decrypting their disks at boot, protecting the system from runtime attackers, attesting to the integrity of their systems, and so on. safeboot and tpm2-attest are (early versions of) those tools!
System Management Mode (SMM), often referred to as ring -2, is an operating mode in x86 computer architecture that is notoriously difficult to debug and secure. To system software including the hypervisor and kernel, SMM is a lurking black box that can asynchronously take control of all system processors for an arbitrary duration of time leading to unpredictable performance degradation. SMM code is stored on non-volatile storage such as SPI flash and loaded during firmware boot alongside other UEFI code. Over time, SMM’s ubiquity and power has attracted platform manufacturers to accumulate implementations in SMM for a growing amount of technologies that require low-level chipset access.
Platform Runtime Mechanism (PRM) is a feature that reverses this trend. It transitions code out of SMM and into the execution context of the OS/VMM by taking advantage of the fact that some code doesn’t require SMM privileges. PRM handlers execute in ring 0 just like other kernel code and can be updated in the OS without resetting the system. Developed in collaboration between Intel and Microsoft, SMI handlers are being ported to PRM handlers today. This talk will primarily discuss the fully open source UEFI code made available for any platform vendor to painlessly enable PRM in their system firmware. It will also cover changes in the ACPI Specification, the open source ACPICA iASL compiler and operating systems such as Linux and Windows to add support for PRM.
When Linux, and it's open-source development model became a real alternative to operating systems like Solaris, AIX and Windows in the late 1990s, it became obvious that it would need more than higher quality code to succeed. They needed to defeat the fear, uncertainty, and doubt coming from Redmond, as well as catch up with technologically superior solutions from Palo Alto.
Deploying open firmware is about building an ecosystem, not just deploying a binary. This talk will present an overview of how Facebook is building that ecosystem, the challenges they have come across along the way. This should be of value to anyone working to effect such large-scale change in their ecosystems.
In this talk I want to show the details of System Transparency's bootloader implementation. While the general ideas of System Transparency has been introduced during the last year, this talk will give insights of one of its core components — the stboot bootloader.
Although this project is still in its infancy, I will present the state of development. Thereby I provide a look back to early beginnings, the design goals, features that have been added in the course of the last year and recent security improvements. Further, design decisions the project is currently facing will be discussed. Finally, the different deployment scenarios are presented which give detailed information about how to use stboot in individual server fleet setups.
There is already no shortage of boot loaders for Linux, but Linux Kernel based bootloading via kexec has become popular as it provides the following distinct advantages:
• Reuse kernel drivers, • Provides userspace, simplifying development, • Platform independence, and • Well tested.
Boot loaders like GRUB provide several advanced features but they need to replicate functionalities similar to OS, which creates an ever increasing maintenance burden.
Kexec lets you boot your Linux kernel into another kernel without going through the hardware reset and reinitialization performed by system BIOS/firmware:
- Improves boot reliability by replacing lightly-tested firmware drivers with hardened Linux drivers.
- Hardware reset and reinitialization performed by firmware takes minutes, being able to skip it reduces downtime.
- Proven approach for several years – many kexec based bootloaders are already available 
. linuxboot: https://www.linuxboot.org, petitboot: https://github.com/open-power/petitboot
However there is scope for improvement  - several Linux drivers don't yet implement .shutdown() callback, which means that kexec boot'ed kernel may panic. Let's discuss these to-dos needed to improve the kexec based bootloaders.
. 10a663a1b151 ("ata: ahci: Add shutdown to freeze hardware resources of ahci"), 428c491332bc ("net: ena: Add PCI shutdown handler to allow safe kexec").
In May 2020, initial support for unit testing the coreboot landed in the tree - it was included in the 4.12 release. The unit testing infrastructure means to help the developers write unit tests in a structured and consistent manner across the whole project. Beside the core build system changes, the patchset comprised documentation with a rationale and test examples. From that time, a couple of new tests were upstreamed together with fixes for the firmware code being tested. Passing unit tests suite is currently one of the requirements for changes to be accepted upstream - this is embedded into the gerrit CI system.
This talk will present why and how the coreboot benefits from unit tests. It will also show more details about the implementation and how to build/run tests. Furthermore, the talk is meant to discuss the challenges of unit testing C code (specifically firmware) along with the plans for the future.
With its rich feature set, regular release cycle cadence, and adoption into silicon vendors’ board support packages, it is no wonder that the Open Source Das U-Boot bootloader has become so ubiquitous throughout products spanning a breadth of application domains. However, much of what makes U-Boot so helpful to embedded systems engineers can be a double-edged sword; permissive functionality and readily available reference configurations represent a form of “security debt” that must be paid off by the engineering teams integrating U-Boot into their product. In both public research and private security assessments, it is commonly found that devices are vulnerable to abuse as a result of product vendors failing to invest adequate time and effort into securing their U-Boot configurations and customizations.
This talk will describe common security failure patterns observed during security assessments of products using U-Boot, introduce NCC Group’s “Depthcharge” toolkit built to support U-Boot security auditing, and present its new functionality that is aimed at providing engineering teams with a means to avoid inadvertent inclusion of functionality that may be an ill-fit for their specific security objectives. At a higher level, this talk aims to foster discussions about how we call all help ensure that product development teams customize, configure, and deploy U-Boot more securely, such that end users remain safe.
EDK2 firmware for Marvell Octeon TX2 CN913x chips can now be built entirely from public components. It was possible thanks to the recent upstreaming efforts to the TF-A and the Tianocore edk2-platforms mainline repositories. As this platform is a straight line successor of the Marvell Armada 7k8k SoCs family, its open source firmware support originated in 2016 and was one of the first ARMv8 ports published. This talk will describe the mentioned systems and their firmware structure. It will also demonstrate the evolution from the early days until present, as well as the future plans in the context of the new SystemReady ES compliance.
Security Protocol and Data Model (SPDM) is a standard published by the Distributed Management Task Force (DMTF) organization Platform Management Components Intercommunication (PMCI) working group. SPDM’s vision is to resolve the long-lasting problem of compatible secure communication solution between two endpoints of embedded systems. To this end, SPDM defines message formats, data objects, and sequences for performing message exchanges. The protocols defined by SPDM can be used for a wide range of security functionalities, such as authentication of hardware / firmware identities, delivering measurements and performing attestation, and session key establishment.
This presentation introduces the open-source tool - OpenSPDM. The OpenSPDM is written in C. It implements an SPDM requester utility to validate a vendor’s responder implementation. It also implement an SPDM responder utility to validate a vender’s requester implementation. The talk covers SPDM 1.0 device authentication and firmware measurement collection and SPDM 1.1 session creation for the data communication protection.
The audience will learn the main components of the SPDM protocol. A firmware solution builder will learn how to implement an SPDM requester to perform the device authentication and attestation and create a secured session with a target device. A device builder will learn how to implement an SPDM responder to respond to the authentication and measurement requests and create a secured session to protect the communication.
The fwupd project is an established open source project being shipped by default on almost every Linux distribution. It is responsible for deploying over 18 million firmware updates. The project supports dozens of existing standardized update protocols like ATA, NVMe, DFU, UpdateCapsule, and also supports many vendor-specific protocols from the likes of Wacom, Logitech and Synaptics. This presentation will explain how the daemon decides to offer a firmware update, and also the low level detail of the flashing process. Tasks like switching the device to and from bootloader mode will be covered, as will how to parse a custom firmware image format.
Some familiarity with how firmware is deployed would be advantageous, but detailed knowledge of how to write GLib C code is not required, but would be helpful. In the presentation I’ll be showing how to write a fictitious plugin for some toy hardware, and show how to debug and test the low level vfuncs before installing the plugin and using it as part of the installed daemon.
This talk would be really helpful for any people interested in porting custom flashing code to the generic fwupd infrastructure. It would be also interesting for anyone who wants to start building and testing the existing plugins from the development branch.
coreboot is an open source firmware development framework and its history is
reaching 1999. Its primary goal was to boot the machine as fast as possible and
launch a Linux kernel. OpenPOWER firmware has a similar goal: initialize the
hardware and launch a Linux kernel. coreboot has always been in favor of open
hardware and open firmware solutions. The best proof is that the first open
firmware implementation for RISC-V appeared right here, in coreboot. Now the
time comes for OpenPOWER.
This talk will describe the plans of porting the POWER9 architecture to
coreboot along with Talos II and Talos II Lite machines. With joint cooperation
of 3mdeb Embedded Systems Consulting, Insurgo Technologies Libres/Open
Technologies and Raptor Computing Systems this plan may become a reality in the
near future. In this presentation the details of coreboot port for POWER9 will
be discussed covering hostboot, skiboot and petitboot and how they fit into
coreboot firmware model.
Although the coreboot project aims to support fully open source boot firmware,
it is not always possible to avoid binary blobs that initialize hardware. A
good example of such a situation is modern x86 architecture. That is why we
need to push open hardware and firmware such as RISC-V and OpenPOWER. By
enabling POWER9 hardware in coreboot, the OpenPOWER will become much more
popular. The community will have a chance to benefit from using coreboot on the
open platforms such as Talos II and Talos II Lite, platforms which respect your
Adding a Trusted Execution Environment (TEE) to OpenBMC will allow for a
variety of useful features in the realm of security. One current feature the
BMC suffers from is the ability to securely store any information. A glaring
example of this is that IPMI user passwords are required (by the specification)
to be available as plain-text to be used in RMCP+ authentication. But because
the BMC currently has no method of securing any secrets, it is impossible to
securely encrypt those passwords. Adding a TEE using the ARM TrustZone
extensions will allow this exact scenario to be fixed. But adding a TEE isn't
so simple as just adding a new package to the OpenBMC Yocto build. This talk
dives into the details of what hardware requirements, boot requirements, and
other prerequisites are necessary to be able to securely store secrets on the
BMC. In addition, it looks to future work that can be done with a TEE besides
simply keeping secrets.
This session details AMD’s journey to align with Industry direction of open source firmware stacks. It focuses on the collaborative efforts to enable OpenBMC on AMD customer reference boards and upstream support for AMD system interfaces to enable our customers, partners and BMC vendors. Finally, it highlights how AMD’s OpenBMC engagement quickly enabled a large number of partners to open source AMD specific interfaces.
The new Intel Atom x6000E series features a Programmable Service Engine (PSE) which supports out-of-band and in-band remote device management; enhanced I/O and storage options; and integrated 2.5 GbE time-sensitive networking. The PSE is based on ARM Cortex-M7. This presentation will focus on the mechanisms by which PSE firmware work with system boot firmware. In addition to that, we will be sharing about the different open source software tools to support the development, integration and design considerations between the PSE firmware and the rest of the system boot firmware. The key benefits from this session is to be able to learn about how to develop and customize the PSE firmware to provide value add for Intel platform.
With the advancement of open source firmware projects, we need a reliable quality assurance process to automate the firmware level testing. In this talk we would like to talk about ConTest - a modular framework aimed at automating system testing workflows and how one can build board-specific testing infrastructure on top of it.
ConTest aims to provide maximum flexibility to the users and to validate as much as possible at the compile-time as well as at job submission time to avoid unnecessary operations. ConTest provides a modular and pluggable set of interfaces to define and handle operations like fetching information of the systems to run the tests on, testing the initial state of the test systems, implementing system-specific actions & measurements and logging the test progress as well as final results. On top of this, ConTest’s test system uses the same framework for testing the correctness and reliability of its own plugins. This talk will also cover the existing plugins provided by upstream ConTest for different parts of the framework while outlining the process of creating the pluggable modules.
This talk will discuss project X, which is aimed at eXcising binary blobs from the x86 part of Zen CPUs. These parts start with fully functional memory, courtesy the ASP (which is a bit slow to get it done, but it gets it done). Getting memory working is just about the hardest part of bringing up a platform. Since the x86 is released from reset with memory working, things are easier.
In this talk I'll go over how we got to our goal, with both oreboot and coreboot, and why we might prefer one over the other.
During this talk, I will introduce my ongoing work to port linuxboot on HPE platforms. The various strategies taken, the challenges we face and how we will address them. A live demo of linuxboot on HPE platform will be performed.
TrenchBoot is a young open source project aiming at security and integrity of
the boot process leveraging advanced silicon security features, like Intel
Trusted Execution Technology (TXT) and AMD Secure Startup. It integrates with
open source projects like GRUB2 and Linux to perform a measured launch of the
operating system software, also called Dynamic Root of Trust for Measurement.
The presentation will describe the progress of the project, what new features
has been added and what we managed to achieve so far.
In particular 3mdeb has been developing support for the AMD Secure Startup.
Since last year we managed to push the project even further thanks to the
founding from NLnet Foundation, NGI Zero PET grant. The most key changes
introduced into the project are the DRTM event log and the possibility to boot
Xen Hypervisor with measured launch. If you want to hear more what is on our
roadmap and what problems we are still trying to solve, this presentation is
oreboot is a downstream fork of coreboot, with all C removed, and all code written in Rust. Since we spoke of oreboot a year ago, a lot has happened, and we want to go over the status.
Since 2012, Google has developed an open source embedded controller for Chromebooks. Recently, Google has committed to use Zephyr OS in future embedded controller designs. We discuss the benefits of moving to a community-driven RTOS instead of using our custom kernel. We also discuss Google’s plans to contribute to Zephyr OS.
Arm SystemReady is a new program bringing a level of consistency across a broad range of Arm-based devices in the cloud, in the network and in high-performance IoT (HPIoT) endpoints. It includes new set of standards and a compliance certification program, with the goal of ensuring that Arm systems "Just Work" with standard off-the-shelf operating systems and hypervisors. The program is based on a set of minimum hardware and firmware requirements. Firmware standards such as UEFI, ACPI, and SMBIOS are key elements in these requirements. This talk introduces the Arm SystemReady program, the Base Boot Requirements (BBR) and the Base Boot Security Requirements (BBSR) firmware specifications. The session show-cases enablement efforts for devices under this program, using open source firmware projects such as TianoCore and U-Boot. It also highlights open source firmware test suites used in SystemReady certification.
When developing an IoT product, the most useful feedback comes when the end user has the product in their hands and when the product is paired with its intended user experience. Unfortunately, traditional approaches to hardware development don’t get to that step until late in the development process, making any changes expensive and time-consuming.
For example, just turning on an LED remotely requires a user experience both in the interaction with the physical product and with the remote interface. The electronics at minimum include a microcontroller, a connection path to the internet, an LED, and some way to provide power to it all. Then firmware on the physical device and software on the server and remote interface on a phone or computer must all interact with one another to deliver the necessary data and commands. The user experience can easily feel disjointed when all of these pieces are not considered and designed simultaneously.
In this talk, you’ll learn how combining agile development practices with open source and/or reference designs can change the narrative on how quickly custom IoT solutions can be developed. Ultimately, this approach provides a higher degree of confidence when the time comes to spend thousands (or tens of thousands) of dollars on hardware.
I started my first reverse-engineering in 1995: NetBIOS "Network Neighbourhood" for Samba 1.9.16p5. I quickly moved on to NT Domains 3.51: "Welcome to the SAMBA Domain" and helped bridge the yawning chasm between UNIX and Windows. By 2003-2004 I had moved on to the Xanadux Project, owned 9 HTC WINCE Smartphones and successfully reverse-engineered Linux onto two of them.
Then Android happened. only a few years later, mjg59 published a review of devices and found a 98% GPL Violations rate.
This brief talk invites skilled dedicated Libre/Open engineers to consider this rather delicate and simple question: why are we doing this? Why are we spending vast amounts of time and effort - mostly without being paid - taking 3 months to 3 years to reverse-engineer hardware that was a design concept at least 12 to 18 months before it first hit the shelves?
Internet of Things projects are challenging because they contain comical exaggerations of the pitfalls you find in distributed systems. In the case of developing a Solar Microgrid Controller, like I did, you'll face bonus challenges like, "When will the internet be in town?", "How do I create clean architecture when the hardware is shifting under my feet?", and "How do I quickly pivot to a different peripheral?"
In this talk, I'll share some of the ways our team leveraged Elixir, Nerves, and NervesHub to build robust Solar Microgrid Controller firmware. I'll also share development patterns and practices that you can take back to your next firmware project.
Because micro grids can be deployed in remote locations without reliable Internet access, data minimization is a must. We'll talk about the tools you can use to provide full utility data when low bandwidth internet might not be in town until next month.
Next, we'll look at a couple of different ways Nerves and Elixir can keep our software tidy by decoupling the firmware from the hardware.
We’ll wrap up by looking at hardware. While commodity hardware like BeagleBone or Raspberry Pi are great for prototyping, they're far too expensive for mass production. For this project, we built our own custom hardware and ported Nerves to it. We'll take a look at some of the considerations you might make if you develop for novel hardware, and what you might do to bring your next project to life with Nerves.
I don't have to go through them — you've heard all the reasons why your company can't adopt open source firmware technology. Sure, you and I know that they aren't great reasons, but how do you provide a more compelling argument for open source firmware?
As the Director of Engineering for a large IoT consultancy, I routinely bridge the gap between business stakeholders and engineering. I've spent a lot of time thinking deeply about why open source is the best business choice, and how to communicate these reasons to business stakeholders both internally, and within many of our largest clients.
We have to face it, the fate of the open source firmware community depends on buy-in from stakeholders in an industry that differs drastically from the college dropout CS student-turned-CEO world of web development. We need to present strong, cohesive, business arguments in order to bring our open source vision to life. I'll share what's made me successful in this domain, with the hope that others can take it and convince more companies to adopt open source firmware.
Currently bootloader systems on Intel platforms requires rebuilding of firmware image to change any Platform parameters through static configurations. Using Platform configuration utilities, we want to provide an OS agnostic GUI solution in payload stage, where the users would be able to configure platform settings on runtime on devices directly. This would largely simplify development/validation/debug process, make it faster, user friendly and provide user much more flexibility. With this on-the-fly functionality, we will able to provide more control to the user without the need for building & flashing the firmware images.
This talk will introduce some work in progress activities to enable Rust in EDK II.
The session will include use cases for Rust in EDK II, advantages of Rust when applied to firmware components, limitations in firmware environments and the types of issues that can be avoided by leveraging language based security in EDK II. Memory safety issues contributed to approximately 70% of recent security issues in software (per MS). In firmware, over 50% of reported issues in EDK II open source are related to memory safety. Future looking directions will also be shared.
webboot is an open-source tool to boot live ISO images from the web. Users have the option to set up a wifi connection and download a new ISO, or use a previously downloaded one. Once the ISO exists locally, Webboot locates its kernel and initrd, determines the necessary kernel parameters to boot, and uses kexec to boot into the new distribution. Webboot was introduced at last year’s OSFC, but several major changes, including the addition of a text-based UI and a cache of previously downloaded ISOs, have significantly increased the tool’s usability.
The design methodology of viewing system firmware functionality as made up of two distinct phases – initialization and OS boot logic is gaining traction resulting in new implementations of system firmware. This approach calls for modular phases with an initialization phase (bootloader) which completes the system initialization and gets the hardware to a usable state and then a payload phase. The payload can provide/implement many different functionalities including the media and file system drivers, operating system boot, diagnostics, etc.
This topic presents the idea of a standardized interface that the bootloader exposes with the design goal of a platform independent payload.
Project Mu Session with Jeremiah Cox
Time is show in CET
SeaBIOS is generally used as CSM on QEMU to boot legacy OS with UEFI BIOS. However, to achieve the same goal on physical hardware is not straightforward and we're facing challenges. We're able to overcome all these challenges and successfully boot legacy OS almost from all kinds of medias(SATA, NVMe, PXE, etc,) by applying various extension and subtle changes on physical server computers. In this presentation, we'll highlight the changes and extensions we made on SeaBIOS. For example, PCI rom BEV(e.g. iPXE) boot support, 64bit MMIO support by BIOS provided SMM, >128K pci oprom memory support, boot event log sent to BIOS(by SMI), VGA console to Serial console redirection, map hard drives dynamically to support more than 2 hard drives, timer/clock fix to support pci rom dispatching, and so on.
Intel® Trust Domain Extensions (Intel® TDX) introduce architectural elements to help deploy hardware-isolated, virtual machines (VMs) called trust domains (TDs). Intel TDX is designed to isolate VMs from the virtual-machine manager (VMM)/hypervisor and any other non-TD software on the platform to protect TDs from a broad range of software.
This presentation introduces the architecture for TDX Virtual Firmware (TDVF), and the firmware reference implementation available in open source. The talk covers how TDVF runs from the TD reset vector, records runtime measurements, manages private memory, interacts with the Intel TDX module in Secure Arbitration Mode (SEAM), and loads the operating system (OS).
The audience will learn the role TDVF plays in setting up and protecting a TD and how Intel TDX establishes a chain of trust from reset vector to OS handoff.