Open Source Firmware Conference 2018

Firmware track keynote

Firmware security track keynote

LinuxBoot replaces most of the firmware image with a Linux kernel and a tailored initramfs. We started the LinuxBoot project in Jan 2017 at Google. In March 2017, we opened the project to the world. Since that time, Facebook, Horizon Computing, Two Sigma, and others have joined the project. It has also become a project at the Linux Foundation as well as becoming a core part of the Open System Firmware project at the Open Compute Foundation. The project is moving very quickly, with sales of zero LinuxBoot systems in 2017, and several tens of thousands in 2018. We expect the project to continue to grow. In this talk, we will provide an update on LinuxBoot, how we integrated it into UEFI and coreboot, and describe the different efforts using it and how you can get involved.

The Armv8.4 architecture will introduce support for virtualization in the Secure state. A new privileged exception level Secure-EL2 will be added that mirrors the existing EL2 in the Non-secure state. https://docs.google.com/presentation/d/1qdQ0eBlby7sJtK0iPX1g2IsCMIqZxvm3QdFSxKhbZyE/present?slide=id.g4085d0d775_0_325 To take advantage of the new possibilities, this opens up arm is currently working on a software architecture advocating the breaking down of secure services into several secure payloads, called Secure Partitions. Mainly, they are software sandboxes used to instantiate management or security services in the Trusted World. They run under the control of a high privileged software component called the Secure Partition Manager (SPM). As secure services might have been developed independently of each other, they might be unaware of the services provided by other partitions and compete for the same resources. SPM is the critical component that guarantees that secure partitions run isolated from each other, while being able to communicate with each other or with other software components in the Normal World. This presentation will give an overview of this software architecture along with details about the SPM reference implementation that the Trusted Firmware-A ill eventually provide. For more details about the Trusted Firmware-A open source project in general, see: https://github.com/ARM-software/arm-trusted-firmware/

This is meant as a follow-on presentation to my 'coreboot on ARM' overview from the 2016 conference (http://youtu.be/z-KpAA4_afs) with the goal to present 64-bit differences in the architecture itself and the way coreboot deals with them, with particular focus on the runtime resident component lifted from the Arm Trusted Firmware project. I'll give a basic developer overview of the Trusted Firmware codebase and what parts a new platform port needs to implement to be usable with coreboot. There may also be some war stories from our recent RK3399 implementation.

Sound Open Firmware (SOF) is a permissive licensed open source audio DSP firmware and SDK that provides infrastructure and tools for audio DSP developers. This presentation will tell the story of how Intel took a historically closed source firmware with a proprietary SDK and created an open source firmware with opensource SDK. It will also describe the technical and non-technical challenges that had to be overcome in releasing open source audio firmware and creating a free SDK. Finally, the presentation will provide technical information about architecture, tooling and how to get involved.

Google Secure Microcontroller (aka H1) is a chip which is in the root of Chrome OS security system. It both plays the role of the TPM and a debug controller which allows access to internal consoles, updating the firmware, etc.

Back at the beginning of home computers, volatile memory was a rather easy problem to solve in the computer architecture, but with the computers getting faster and multiple cores, it has become a surprisingly tricky problem for processor and chipset designers to solve. This talk tries to shed some light on the difficulties of implementing high-performance memory subsystems and how solutions to those difficulties affect the design of RAM, memory controllers, cache subsystems and even the microarchitecture of the processor cores.

Researchers from Intel's Platform Armoring and Resiliency team will walk through the evolution of various firmware threat models as a result of the low-level skill advancement of software and hardware adversaries. In response, TianoCore added new in the UEFI Development Kit 2018 (UDK2018) release, along with enhancing existing security features. This session provides real-world examples of several attack classes along with effective mitigation techniques against them. Topics include an introduction to platform security, an update on changes to the UEFI threat model, and a walkthrough of a critical Unified Extensible Firmware Interface (UEFI) security features (ex: HTTPS boot, pre-boot DMA protection using VT-d, guard page protection for potential stack/heap overflows).

coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. The fact that BIOS or Intel firmware touches many restricted register settings which are not exposed to the external world is one of the major challenges for coreboot and that is being addressed by FSP (firmware support package) like binary blob solutions. Any coreboot project can be split into three parts • SoC – This section contains all components/IP initialization code. • Mainboard – OxM boards, build based on underlying SoC support. • FSP – Intel Firmware Support package to abstract all restricted soc registers from open source world and kept inside a binary blob. This paper will explain how the open source community can use FSP 2.0 to create their mainboard based ports based on a supported SoC.

I invented the ramstage in late 1999 because Linux could not enumerate PCI correctly. Since then, the ramstage has grown in complexity. On one port (RISC-V) I observed that the ramstage was not really needed. In more recent work on LinuxBoot, we've also found that we don't need the ramstage in some cases. If the romstage could load a payload directly, then we'd save some steps. The romstage on LinuxBIOS V3 could in fact do this, and in this talk I discuss our experiences in restoring rompayloads to coreboot.

We take a look at differences observed in firmware security posture as mapped by CHIPSEC on a custom Winterfell node AMI based firmware vs. LinuxBoot w/ u-root. Using the findings as back-light, we also give an introduction to: a) tools for conducting firmware security research - Flashrom, Chipsec, Dediprog, Winterfell standalone node and a few more. b) alternatives to manufacturer firmware like LinuxBoot w/ u-root c) also demonstrating web-based: i) in-depth analysis for submitted firmware images - It's " brain " is growing at a healthy/steady clip of firmware already analyzed. There is also a cmdline JSON based API for it that will be made available during the talk. ii) Winterfell access with bios emulation - service is now in alpha with full shell access within a subset of u-root community with following functions all on point ( these will eventually be available as API ) : - Get SPI Flash emulator status - Stop emulator - Start emulator (the firmware parameter is the firmware the user wants to be tested) - Start the server through hard power on - Stop the server through hard power off

The idea for this talk born from fascination about the philosophy behind QubesOS, OpenXT and ViryaOS. The underlying technology for those OSes is Xen. Xen is a well-known project under the Linux Foundation umbrella, but what is most interesting in it from open source firmware perspective are high-end virtualization features like: * DMA protection * PCI pass-through * Interrupt remapping * SR-IOV * TPM and vTPM * others With automotive market hypervisors slowly move into embedded space, what means underlying firmware will have to expose right infrastructure to provide initial configuration and security. Most features have to be configured and exposed in a well-defined way by firmware. IOMMU is the system component that some of the mentioned features rely on. As maintainers of PC Engines apuX platforms, we decided to work on AMD IOMMU enabling to create right infrastructure for hypervisors and operating systems. In this presentation we want to: * explain features of AMD IOMMU * present recommended methods of AMD IOMMU enabling * demonstrate current status of our work * discuss future user needs and implementation plans

BMC (Baseboard Management Controller) is the intelligent controller embedded into complex data center equipment like servers, storage systems, and network switches allowing systems to be managed efficiently. The firmware stack for these controllers has been proprietary and closed until recent times. This situation has been changed with the start of the OpenBMC project. This talk is aimed at introducing OpenBMC as an open source alternative firmware stack for the audience. In this talk, we will go over typical at-scale data center use cases for system management, understand the challenges/limitations in proprietary source base, look at the history/evolution of OpenBMC project.

UEFI is a de-facto standard BIOS for x86 based computers. Currently, there are two types of UEFI implementations, TianoCore and closed firmware developed by BIOS vendors. The latter has problems that the users can not fix the bugs or the code shipped without enough verifications. TianoCore is an open source UEFI. However, its code base is too big in the view of booting OS. Thus, it is not suitable for embedded systems or bare metal clouds. To solve these problems, I propose yabits, a new UEFI implementation. I confirmed that yabits is small footprint and boots fast compared with other UEFI implementations.

An overview of the "Dynamic Tables Framework" submitted to Tianocore edk2-staging. Provides an outline of the design intent, as a basis for discussion on future possibilities. This is fundamentally the same paper as presented at UEFI Plugfest in May.

We will talk about the open source system firmware development that is going on at Facebook. We will discuss the reasons behind working on open source firmware, and why we chose LinuxBoot as our firmware platform of choice. We will also show systemboot, a "distribution" for open source bootloaders based on u-root, and how this fits together with coreboot and LinuxBoot.

From humble origins as a bootloader for the Playstation 3 to being loaded on every OpenPOWER server, it has been a big four years for Petitboot. First debuting on IBM's POWER8 S812L server in 2014 Petitboot is now the primary bootloader for every OpenPOWER machine, from Raptor Engineering's "TALOS II" workstation to IBM's AC922 and Supermicro's "Boston" servers which power the Summit and Sierra supercomputers which took out 1st and 3rd place in the Top500 in June. Petitboot uses kexec as its booting mechanism meaning that while it is the primary bootloader on OpenPOWER machines, its flexibility means it is just as relevant for x86 and ARM machines and has even recently found adoption outside of the POWER architecture. In this talk, we will cover the Petitboot bootloader; what it is, how it works, the positives and the challenges of delivering an open source bootloader, how it fits in with the current bootloader ecosystem, and where we see Petitboot going in the future.

This talk covers chain-loading U-Boot on a Chromebook as well as experimental work on using U-Boot as the primary bootloader on eval boards such as Raspberry Pi (with verified boot). This provides a means to make use of Chrome OS's excellent vboot/update system, without needing to change over fully to the Chrome OS environment. Part of this work builds on 'binman', a program used by U-Boot to build firmware images consisting of a number of 'entries' of different types. Binman is extensible, allowing new types of entries to be created easily. It is efficient, able to create complex images in O(#entries) time. A demo will show U-Boot's sandbox environment running through the verified boot flow.

Chrome OS has gained a lot of popularity in the EDU market. Recently, it has started expanding to consumer segment with devices like Google Pixelbook, HP Chromebook X2 detachable, Samsung Chromebook Pro and much more. All the Chrome OS devices (except a few early ones) use coreboot as their machine initialization routine irrespective of the underlying hardware architecture (x86, ARM, ARM64, MIPS). With more and more OEMs coming onboard, there is always a race to build and ship these devices at a quick pace. Google follows a reference model scheme to allow OEMs to pick a validated platform and add their customizations on top of it. This presents an excellent opportunity to reuse a significant portion of the work that is done for a reference platform across multiple devices. In order to provide reusability of components within coreboot, some features have been implemented over time. This talk provides an overview of the reusability features within coreboot including SSDT generation, variant structure, device tree override and more. It also presents currently unsolved challenges that can greatly reduce the time and effort required to add new devices to coreboot.

Nowadays, a significant number of devices are supported by free software projects related to hardware support, such as coreboot, U-Boot and ARM-Trusted-Firmware, sometimes without any proprietary blob left in the boot process. While each device and associated platform presents various specificities, they are abstracted away by generic software interfaces in upstream projects, where the source code for all the supported platforms and devices is merged in a single tree. However, the installation process for deploying the software on an actual device is not always straightforward, especially when starting with building the code. Although each project may provide (more or less comprehensive) instructions for producing a software image for the device, the required procedure for preparing and installing the produced images to the device can be rather technical and complex. These steps are generally specific to the platform or family of the device and often involve specific tools. Origami-Paper is a project that aims to ease the development, preparation and installation of free software and logic configuration projects related to hardware support. Technically, it consists of a build system with a collection of scripts, which provide a consistent interface to build, prepare and install upstream free boot software projects for specific devices. They allow simplifying each action involved in the process, by bringing the focus away from the specifics of each project's build system and usage, including tools specific to the device, platform or family. By reducing the overhead of the process, using free boot software becomes more accessible to non-developers! The Origami-Paper project will be presented through an overview of the rationale behind it, its development, its features and examples describing how to use it in practice. Additional areas of focus of the project will also be mentioned, such as automated deployment and providing information about the support status in free upstream projects related to hardware support for specific platforms and devices as well as documentation and both source and binary releases.

During the last 2 years, U-Boot has grown support to execute UEFI applications such as grub or various BSD loaders. This presentation will show you the progress of what is already working. It will show how far we're away from passing the official UEFI test suite and give you reasons why supporting UEFI binaries in embedded environments is useful.

Facebook has been working on an open source Board Management Controller (BMC) solution since 2014. This presentation examines several specific problems discovered, as usage of the embedded Linux distribution has grown. Out of Memory in 1 to 60 Days, or Why to Engage Upstream and Rebase Often Two memory leaks, one in Linux v2.6 and the other in rsyslog, and how they were fixed upstream. The Pain of Passwords, or Why to Invest In Security Several shortcomings of passwords we have encountered, how to set up SSH Trusted CA and Authorized Principals, and password and key rotation considerations for image update and configuration mechanisms. Unresponsive Endpoints, or Why to Architect and Test for Resilience Communication failures observed between bootloader and BMC over IPMI, or between BMC processes over Unix socket, the code or system design changes which improved things, and how testing can screen for these issues.

We will introduce during this talk the work that we perform to automatize firmware testing based on linuxboot firmware project. The intend is to analyze the various challenges faced during CI implementation including node bricking management, firmware upload to testing nodes as well as testing result analysis. Our work is performed on Open Compute Hardware.

This workshop will be focused on Origami-Paper, with the intent of both assisting users of the project and adding support for more devices that can run with free boot software such as coreboot and U-Boot. In particular, we are aiming at integrating support for the Intel-based laptops supported by coreboot that can boot without proprietary blobs.

The board management computer (BMC) is a component of the modern server allowing administrators to manage the server as if they were locally present. Over the recent years this component has come to be criticized for the many security issues that have surfaced, and until recently this component has been a very black box for the end-user. In this talk, we will briefly look on what the BMC does and how we can implement these features as part of the u-root Golang userland stack.

The Internet of Things (IoT) presents new opportunities for business and industry, as well as some design challenges. IoT firmware must address the dynamic requirements of security, speed, size, licensing, and functional safety for a variety of use cases and operating system requirements. Product Architects and Designers need IoT boot solutions that address these challenges while also being mindful of existing standards and libraries. This session discusses the important role firmware plays in IoT designs as well as how a new open source firmware solution that leverages libraries from TianoCore and EFI Development Kit II (EDKII) complements existing firmware solutions in the IoT market.

This workshop demonstrates how to compile and build UEFI platform firmware based on the open source EDK II framework at tianocore.org. Examples are based on the Open Virtual Machine Firmware (OVMF) project, which generates a firmware for the Quick Emulator (QEMU) environment under Linux*. Further examples show the benefits of using OVMF to understand UEFI and EDK II architecture. Participants will set up an EDK II development environment for Linux, build the OVMF platform, use their custom firmware to boot a QEMU environment, boot to the UEFI Shell, and explore common UEFI Shell commands used for firmware debugging. Installing Docker instructions, please click on workshop material: https://github.com/tianocore/tianocore.github.io/wiki/Container-for-OSFC-Workshops

As PC Engines firmware maintainers and aspiring IBV, we face lots of different issues with development. Critical bugs and regressions are our biggest enemies. Narrowing down serious problem requires a lot of repetitive work. The typical process looks like that: 1. modify & build firmware with a potential fix 2. flash affected firmware version 3. boot system 4. verify if the bug still exists This can take more than 10min and requires human attention not to make a mistake. If you work hours on one issue, this can be boring and at some point, you will make mistakes which can affect results. Automation of point 1 is already done by coreboot-sdk. It also can involve user-developed scripts. Points 2-4 can be automated using RTE. Another issue is that platforms and quality firmware developers are spread around the world and we would like to have reasonable access to key features that help in remote development. Because of that, we created RTE. Remote Testing Environment is an open hardware hat designed for Orange Pi Zero board to work with hardware remotely. It takes advantage of using Linux system and open source frameworks such as Robot Framework to let user conveniently develop firmware, test software and/or hardware. With RTE, your everyday work routines become much faster and easier to maintain from places not related to current setup location. Those include flashing firmware, controlling GPIOs and power management for Device Under Test. RTE is released under CERN Open Hardware License. RTE applications: * Remote access / control (hardware functionality) * Remote industrial application debugging * Compatibility testing * Platform enabling * Performance optimization * Automation validation * Manufacturing procedures support Agenda ------------- In this workshop, we want to present how RTE can be used with open source firmware and help R&D and Q&A teams to achieve their goals. RTE workshop main points: 1. RTE features set. 2. Connecting RTE to real hardware (e.g. PC Engines apu2 or MinnowBoard Dual/Quad). * validation setup - run a simple test in RobotFramework 3. Comparison of simple procedures: * firmware flashing (main goal) * present power control possibilities (direct GPIO and Legacy interface) 4. Development workflow with RTE based on the simple bug. 5. Questionnaire and RTE giveaway. Additional information ---------------------- * Level: Intermediate * Workshop will be interactive with examples * There will be a draw between participants, 3mdeb gives away 3 full RTE platforms (worth 85 USD each) * We are not sure we can handle more than 8 attendees * Please, check out our [GitHub](https://github.com/3mdeb/rte-schematics) repository.

Python* is a popular high-level interpreted language, common in automated testing environments. TianoCore includes an open source CPython implementation for UEFI, but it has limited functionality and isn’t compliant with current Python standards. This session describes the process of porting MicroPython to UEFI. MicroPython is a Python 3 variant designed for microcontrollers. Memory and size optimizations make MicroPython ideal for pre-OS applications. This presentation describes implementation details, performance metrics, and an open source test framework based on the MicroPython engine for UEFI.

In this talk, I will discuss the developments in and around coreboot on RISC-V, over the course of the last year. New hardware has been released, new contributors have joined the project, but some challenges still remain.

Logs from coreboot are collected in the board status repository. In this talk, the tools to gather logs are introduced and in the primary part statistics from the data in the board status repository are presented.

This workshop demonstrates how to use the Intel® UEFI Development Kit (Intel® UDK) Debugger with GNU Debugger (GDB) to debug UEFI drivers and platform firmware in a Linux environment. Exercises are based on EFI Development Kit II (EDK II) firmware for the Open Virtual Machine Firmware (OVMF) project. Participants will set up an EDK II development environment for Linux, build a UEFI driver, and debug firmware issues using Linux and QEMU. The workshop demonstrates debug capabilities built into EDK II and how they work with UEFI drivers and platform firmware: • Use the Platform Configuration Database (PCD) to configure debug features • How to debug the various phases of UEFI firmware • Build a UEFI Driver with Debug Symbols • Build a UEFI Driver with Heap Guard Enabled Installing Docker instructions, please click on workshop material https://github.com/tianocore/tianocore.github.io/wiki/Container-for-OSFC-Workshops

CHIPSEC is a security research and validation tool implemented in Python that allows for low-level access to hardware. The powerful scripting capabilities can be used for some tasks, including verification of security mitigations as well future security research. This workshop will provide an overview of the existing tool architecture and how to write modules and tools. Modules will focus on using CHIPSEC for verification of firmware mitigations. Tools will focus on using CHIPSEC to stress the system and perform tasks such as fuzzing interfaces.

With the recent advancement in connected/smart device and availability of ready-made framework for both hardware and software development. Companies want to get into the IoT market rapidly. It is necessary to look at the security feature of these smart devices as our digital lives are connected to these devices. Bluetooth has been around for almost a decade and with the need for low power wireless network and interoperability. Bluetooth has been used in a vast majority of the device because of its small power footprint and interoperability as most of our smartphones have Bluetooth. In this workshop, we will be learning on how to fuzz the Bluetooth LE functionality of smart devices and exploit it. In this version of training, we will work on reversing a Bluetooth LE-based smartwatch/band. In the process, we will learn about how the Bluetooth low energy protocol works and various tools involved in reversing a smart band. We will also introduce a Bluetooth fuzzing framework called as Bluzz and use it to crash or find other information in the smart band. By the end of the class, we will also touch base on the hardware level exploits that is possible with the smart band and some demos on the same.

The U-Boot project has evolved in the time span of over 17 years and so as its complexity and its uses. This has made it a daunting task in getting started with its development and uses. This talk will address all these issues and share development efforts created by the U-Boot community. In this talk Jagan Teki(Maintainer for Allwinner SoC, SPI, SPI FLASH Subsystems) will introduce U-Boot from scratch with a brief overview of U-Boot history, U-Boot Proper, SPL, TPL, Build process and Startup sequence. He will talk about other preliminaries such as Image booting, Falcon Mode, Secure Boot and U-Boot features like device tree, device overlays, driver model and DFU, etc. Once giving enough introduction, he will also talk about steps to port U-Boot to new hardware with a demo, along with U-Boot testing process. Finally, he will address and review ongoing development work, issues and future development regarding U-Boot. About the company: We recently opened Amarula Solutions, India office. https://www.amarulasolutions.com/news/new-office-opening-soon-amarula-solutions-heading-to-india/ Here, we offer solutions around open source software. Our key operating areas are Embedded Linux, Boot Firmware, Mainline, Open source Multimedia, IoT/Android Solutions etc. Whether you have multimedia or web technologies needs, we have unique knowledge in key Open Source projects such as U-Boot, Linux, Buildroot, Yocto, Android, IoT, Qt5, G-Streamer. If Amarula Solutions can help your business and of your project at all please do not hesitate to get in touch with us. Amarula India look forward to hearing from you.

In this presentation, we would like to present how BITS and CHIPSEC can be utilized on top of coreboot enabled platform to verify the quality of underlying firmware. Firmware security is mostly about validation and formal development processes. To achieve some level of confidence about firmware implementation quality various tools were developed, of which most notable are CHIPSEC and BITS. BITS (BIOS Implementation Test Suite) consist of a GRUB2 bootloader extended with runtime Python support. CHIPSEC is a Platform Security Assessment Framework which mostly focuses on platform configuration but can also be used for other purposes (e.g. verification of Spectre mitigation presence). We would like to present what issues firmware developers may face and what we were able to achieve at this ground using BITS and CHIPSEC for validation of PC Engines apu2 and MinnowBoard Turbot platform. We want to present what modifications are required to integrated Python code along with CHIPSEC and BITS scripts. We also would like to demonstrate practical usage of mentioned frameworks by showing short demo.

CHIPSEC is one tool used to help verify that systems meet basic security best practices. In general, this tool works with the threat model used by Unified Extensible Firmware Interface (UEFI) based firmware. However, other firmware may have different threat models that will cause failures in different CHIPSEC modules. This session is a brief overview of the different types of failures that may be seen and the limitations of the tool.

Debugging ChromeOS Devices with SuzyQable

u-root