Piotr Król

In this talk, we'll describe how OpenSecurityTraining2 (OST2) can help grow security talent and awareness on open source projects, and we'll use the coreboot open source firmware as a case study.

Newly structured as a 501c3 non-profit, OST2's core goal is to provide free and open training that helps increase system security. This can take multiple forms, such as training dedicated security engineers, training developers to write more secure code, training potential contributors to security-focused projects, or training engineers on safer alternatives to technologies they're already using. In this talk we'll describe current and future examples of all the previous use cases, and drill deeper into a case study of how 3mbdeb, a licensed service provider for the coreboot open source firmware project, is contributing to OST2 to advance the state of open source firmware security.

Other people: Xeno Kovah

Together with Daniel Smith, TrenchBoot Project Leader, we invite Open Source Firmware Community to discuss various approaches to establishing a root of trust and maintaining its security properties over platform runtime. Initial measurement is crucial to platform security because the code that creates root measurement has to be secured. S-RTM (Static Root of Trust for Measurement) is found at a fixed point in time, which is the beginning of the boot process for most platforms. Typically, it is done by Intel Boot Guard, AMD Hardware Validated Boot, NXP High-Assured Boot, or other proprietary implementations. S-RTM-related measurements are recorded in TPM PCR[0-7]. Those can be used for local attestation (unsealing of secret, e.g., disk encryption password) or remote attestation. Finally, to keep the security properties of S-RTM, there is a need for a mechanism that can adjust firmware measurements after its update. D-RTM (Dynamic Root of Trust for Measurement) can be established at any point in time through dedicated hardware and firmware functions. D-RTM initial measurement happens right before the execution of minimal code called D-RTM Configuration Environment, which establishes a new Root of Trust for Measurement. D-RTM-related measurements are recorded in PCR[17-22] protected by hardware through the TPM locality mechanism. Obtained measurements can be used in precisely the same way as in the S-RTM case. Let's discuss: - update mechanisms - protection mechanisms for S-RTM and D-RTM - future of related functionality - synergy: beyond RTM coexistence

This is the continuation of the "Status of AMD platform in coreboot" presented last year on the Open Source Firmware, BMC and Bootloader devroom. The talk will cover the news around the AMD support in Open Source Firmware ecosystem from the past year. You will hear, among others, about: FSF RYF KGPE-D16 platform revival, AMD Ryzen R1000/V1000 series AGESA integration into open source TianoCore EDK2, TrenchBoot new features and updates and current support of AMD Picasso and Cezanne SoCs in coreboot, pure open-source on AMD Rome platform in oreboot.

The history of AMD cooperation in coreboot projects reaches 2007 where the first contribution appeared for the Geode LX processors. AMD's open-source support continued for many years until now (with some break). This presentation will briefly introduce the history of AMD and coreboot, the evolution of the code, processors, creation of CIMX and AGESA and so on. It will also show the gradual change in the AMD attitude to open-source and introduction of binary platform initialization. Binary blobs, very disliked by the open-source community started to cause problems and raised the needs for workarounds to support basic processor features. Soon after that AMD stopped supporting the coreboot community. Moreover, recent coreboot releases started to enforce certain requirements on the features supported by the silicon code base. Aging platforms kept losing interest and many of them (including fully open ones) are being dropped from the main tree. Nowadays AMD released the newest AGESA with the cooperation of hired coreboot developers, but only for Google and their Chromebooks based on Ryzen processors. 3mdeb trying hard with this ecosystem showing that the AGESA can be integrated into Open Source Firmware like TianoCore EDK2 on the example of AMD Ryzen R1000/V1000 processor. Even FSF RYF KGPE-D16 platform is experiencing its second youth by being revived to the main coreboot tree. If you are curious about these activities and many more like TrenchBoot new features or AMD Picasso an Cezanne SoC support in coreboot, pure open-source on AMD Rome in oreboot, this presentation is for you.

Other people: Marek Kasiewicz

For the last several years, hypervisors have played a key role in platform security by reducing the possible attack surface. At the same time, the hype surrounding computing and Internet of Things Gateways has led to an increase in network appliance devices. Our target was to create a less-insecure virtual network appliance using TrenchBoot, Trusted Platform Module 2.0 and AMD SKINIT Dynamic Root of Trust for Measurement to establish a Xen hypervisor with a meta-virtualized pfSense firewall. We are going to present it with an update of the status of support of TrenchBoot for AMD processors. This appliance is supported by are supported by apu2, a reliable low-SWaP x86 device from Swiss OEM PC Engines. It can be used as a Single Office / Home Office firewall or an industrial edge device and has mostly open-source hardware, coreboot firmware, mPCIe extensibility and an extended support lifecycle for the embedded Central Processing Unit and motherboard. In this talk, we will show how to create a system, which enables a significant portion of computations to the edge devices while maintaining security. Using a simple, well-known platform, we will conduct a secure boot using the Static Root of Trust for Measurement with coreboot, move to the Dynamic Root of Trust for Measurement by SKINIT in TrenchBoot and use all of this to provide a complete chain of trust for the Xen hypervisor, a virtual firewall appliance isolated by an input–output memory management unit (IOMMU) from the physical network interface controller (NIC) devices. We will present benchmark data on virtualization overhead, explain how this complexity can still be practical and outline the value of this stack. In the second part of presentation we will discuss current status of Intel TXT development in the GRUB and Linux kernel.

Other people: Daniel Kiper

In this paper, we are going to explain TrenchBoot implementation for AMD and prove a boot chain leveraging it. We will outline how this solution coexists with open-source firmware like coreboot in flash, explain required bootloader extension based on GRUB2 implementation, discuss Landing Zone (LZ) secure loader implementation and required Linux kernel modifications. Finally, we will explain what benefits this solution has over the previous OSLO, Flicker, Soft Cards and others.

Until now SPI flash memory was not considered to be a storage for a hypervisor, because they were relatively too small. We've embedded Bareflank-based hypervisor into SPI flash to be launched directly from coreboot and load SeaBIOS, also embedded inside SPI flash. For this purpose, we had to change architecture from 32-bit used by coreboot to 64-bit used by a hypervisor, and then get back to 32-bit to load SeaBIOS as a payload. This is a compact solution for multiple purposes using Virtual Machines that provides separation, stability, and security. Fact, that the hypervisor is embedded in the SPI means, that simple disk removal doesn't affect it. In this paper, we will show how we've done it and what are the possible extensions and usages of our concept.

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.

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.

Other people: Michał Żygowski

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