The LinuxBIOS project began at Los Alamos National Lab in Summer 1999, as the first piece of the Clustermatic HPC software stack. Why Linux? Because firmware always evolves to become an operating system. Rather than wait for evolution to take its course, LANL decided to save some time and use Linux as the BIOS: hence LinuxBIOS.

A lot of the early history is contained in mailing lists and web pages, now lost. Thanks to git and the WayBack machine, some of the details can be found. This talk will present details from the very early days to the present of the project itself, and the meta-issues of how the project evolved, how the vendors almost killed it, how Google saved it, and how it is thriving: there are now more coreboot laptops than Mac laptops, for example.

Product presentation.

BMCs have a notorious past of critical vulnerabilities that allow complete takeover of the host system. Worse, the same types of vulnerabilities creep up in BMC firmware over and over again. This talk looks at these repeat offenders in depth to see what can be learned. A comprehensive threat model for BMCs will be presented along with methodologies, practices, and techniques that can be used to avoid these common security mistakes.

Introducing System Transparency - a novel design approach for computer systems intended to offer deterrence, prevention, and detection of attacks by combining a provisioning ritual, write-protected firmware, tamper detection, reproducible builds, remote attestation, immutable infrastructure, and a signed and auditable append-only log. Used correctly it will prevent malware persistence, provide an extensive and trustworthy audit trail, and eventually self-heal after compromise. Within certain limitations it can be used to prove to the owner, system administrator, user, or a third party, exactly what is currently running on the system, and what it has been permitted to run in the past.

It facilitates trust in the hardware and initial state of the system through the provisioning ritual and tamper detection switches, which together with a TPM and firmware write-protection establishes the root-of-trust as well as prevents malware persistence.

The use of reproducible builds in combination with immutable infrastructure deter and prevent malicious modification during the build stage as well as during runtime. The use of remote attestation of the boot chain in combination with a transparency log provide assurances of the current system configuration, as well as an audit trail of previous configurations.

A platform using System Transparency that is compromised due to an unpatched application can simply reboot, load an updated system image, and attest its new, patched, and uncompromised boot chain to its system administrator or users.

The LVFS is a website which allows hardware vendors to upload firmware updates. This site is used by all major Linux distributions to securely provide metadata for clients such as fwupdmgr and GNOME Software. There is no charge to vendors for the hosting or distribution of content, and both the website and client-side mechanism are free software.

Since its inception nearly three years ago, the LVFS has shipped over 7 million firmware files to Linux users, and now updates over 500,000 devices a month. Over the last few years the LVFS has grown from a hobby project with a monthly budget of $22 to a supported project managed by the Linux Foundation. Using the power of open source, reverse engineering and determination we’ve convinced Dell, Logitech, Lenovo, HP (and dozens more vendors) to ship both free and proprietary firmware to Linux users, greatly improving the security of all of our hardware. The LVFS is so ingrained into our ecosystem that increasingly big companies like Google and government departments are requiring hardware to be supported by the LVFS before purchases are approved. Dell even requires all hardware suppliers to use the LVFS too.
Far from being just a giant FTP archive of blobs, the LVFS actually validates and checks the uploaded firmware using tools like CHIPSEC and MEA for common issues. This ensures that firmware problems are caught before being sent to millions of computers. With this analysis, we can also make sure the vendors include all the security issues fixed in the update description without accidentally missing anything out. Users can also provide optional automated and anonymous success/failure reports back to the vendor, so many real-world problems can be quickly identified.
This talk will cover some of the history of LVFS, and detail how we got to where we are today. I’ll show the workflow for an OEM or ODM, and also explain how the automated tests work. They’ll be lots of screenshots and not much writing.

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.

Platform initialization for the majority of the Intel product portfolio is implemented using Unified Extensible Firmware Interface (UEFI) compliant firmware. Historically, UEFI firmware has been built with a PC ecosystem mindset; open standards but closed implementations. Every PC design had a unique implementation with its own issues. In order to address the increased focus on firmware security and cloud workloads, open standards must be paired with open source implementations. This paper summarizes Intel’s renewed efforts to bring open source firmware to contemporary systems.

Platform Management Components Intercommunication (PMCI) is a DMTF standards group that deals with "inside the box" communication protocols for systems such as servers. A couple of such protocols are the Platform Management Data Model (PLDM) and the Management Component Transport Protocol (MCTP). MCTP allows for a media independent communications protocol between hardware components. PLDM defines data models and messages for communications related to discovery, sensors, FRUs, monitoring, and control, etc, between management controllers and devices.
This talk will describe at a high level introduce PLDM and describe the PLDM stack design on OpenBMC. In addition, currently, supported PLDM specifications and features will be described. Finally, there would be a section on contributing and getting involved.
Attached a PDF containing the presentation.

The implementation of SMI transfer monitor (STM) support for Coreboot, will be described in this talk.

An STM is a hypervisor that executes in x86 system management mode (SMM) and functions as a peer to the hypervisor or operating system. The STM constrains the SMI handler, by hosting the handler in a virtual machine (VM). Otherwise, the SMI handler holds unconstrained access to the platform, which could undermine the assurance provided by DRTM or TXT.

We have enhanced the base STM to provide a protected execution capability by extending the STM to support additional VMs (PE/VM) in SMM (STM-PE). These enhancements utilize the existing capabilities of the x86 processor and, thus, require no additional hardware.

The focus of this talk will be on describing the requirements needed to load and start the STM and how those requirements are met in the Coreboot STM support. Some low level issues encountered during the testing will also be covered.

We will also provide a brief description how we are utilizing STM-PE to protect kernel introspection in an internal pilot project.

The OpenBMC platform is a core component in modern server deployment. As such, it needs to ensure that the services it provides are always available to the host system and out of band controllers. Currently, OpenBMC has far from the ideal amount of fault tolerance and recovery in the design of its core software architecture. The goal of this talk is to raise awareness of how OpenBMC currently handles failures of hardware and internal software components, and what improvements should be made if we want to improve the reliability and debuggability of the platform. This talk will address methods for automated health checking and recovery of services within the system, and utilities OpenBMC should provide in order to make life easier for the system operator to monitor and triage failures. We will go over at a high level the construction of the system today, what mechanisms it currently provides for recovery and monitoring. We will dive in to some real failure modes that have been experienced at Google, and how the current system recovered from those failures or failed to provide us with good enough information to triage the issue. The talk will also cover BMC to host interactions, and the configuration options a system integrator has to configure the BMC to provide powerful watchdog coverage of the host system.

The open RISC-V Instruction Set Architecture (ISA) has been growing for the last few years and the momentum behind it is impressive. That does not mean there are no areas that can be improved. For instance, until recently, a major weakness in the RISC-V software ecosystem was the boot loader support. A well-supported and standard boot flow is required before RISC-V can be a truly competitive alternative to existing mainstream ISAs. By focusing on using common open source projects, RISC-V can follow the same boot flow as other popular ISAs, allowing RISC-V to build on past experiences with booting complex systems on various environments.

Although RISC-V is leveraging existing projects as much as possible, RISC-V also needs its own trusted firmware to handle RISC-V specific features such as Supervisor Binary Interface (SBI). SBI allows the operating system to interact with the supervisor execution environment (SEE). This requires a separate but modular open source SBI implementation that provides RISC-V specific run time services. OpenSBI is a BSD-2 licensed project. It is designed in such a way that other open source firmware and bootloaders such as U-Boot, coreboot and EDK2 can easily integrate with OpenSBI and do not require their own separate SBI implementation. This avoids implementation duplication with a common open source SBI implementation.

Currently the RISC-V boot process is functional with U-Boot being used as the last stage boot loader and OpenSBI as the machine mode run time service provider. There is also an on-going effort to port U-Boot and coreboot as a first stage boot loader, a step necessary to provide more advanced boot flows including secure boot. This paper will discuss how the RISC-V boot process compares to other ISAs and where the community is heading. This will give developers more insight into how the RISC-V boot process works and how they can contribute to improve the RISC-V

Intel® Direct Connect Interface (DCI) provides closed chassis hardware debug functionality through USB 3.0 for Intel platforms. Intel also provides Intel® System Debugger which enables deep, system-wide analysis for Unified Extensible Firmware Interface (UEFI), system-on-chip peripheral registers, operating system kernels, and drivers with full operating system awareness.

This session will focus on debugging firmware functionality using DCI with open source EDK II firmware. The AAEON UP Squared board will be used to provide an overview of DCI functionality, feature enabling instructions, and functional demos. We will also show how to run CHIPSEC within the debugger to check security settings and run specific tools.

IPMI (Intelligent Platform Management Interface) is an old standard that was originally created during the time of 8051s and minimal processor capabilities. Security was not really one of the major concerns at the time. Now that BMCs (Baseboard Management Controllers), nearly all of which implement IPMI, are modern 32-bit processors capable of running firmware of substance, security is also becoming a bigger concern.

How do we take an ancient protocol like the command specification in IPMI and implement it in a way that provides some automatic security measures while maintaining code easy to read and debug?

Most BMC hardware is an SoC (system on a chip) that are based on some 32-bit ARM architecture, running at several hundred megahertz. With sufficient RAM and CPU cycles, we can move from assembly to C to C++. Modern C++ provides some powerful tools that can be used to write functions that do much of the tedious (and error-prone) deserialization and serialization of request and response parameters. But just because it is automatic does not mean that it is hard to write or read and debug. Say goodbye to manually parsed parameters and bounds checking on untrusted data. Embrace templates and compiler-generated code.

Traditional cloud computing services utilize virtualization to abstract a physical server's hardware and firmware details. In a bare-metal cloud, users have direct access to the hardware, and to the firmware that runs on the hardware. It is thus in the interest of bare-metal cloud providers to control the firmware running on the servers, rather than to rely on proprietary, black-box firmware. This presentation will look at the challenges involved in replacing vendor-supplied firmware with open source alternatives such as OpenBMC and TianoCore. It will discuss approaches taken to reverse engineer BMC firmware image formats from multiple server vendors, and will also discuss tools created to extract device tree and sensor details from the images to accelerate OpenBMC porting. It will also look at security considerations such as firmware signature verification and real-time modification detection. Examples will be provided based both on work completed and work in progress at Packet Labs, the research and development division of Packet.

The IBM Linux Technology center is developing verified boot and Trusted Computing support for the OpenPOWER bootloader, Petitboot. However, Petitboot is only a thin Linux application that kexec's the OS kernel. We're putting the majority of kernel signature verification and key management functions into the Linux kernel and firmware services. This talk is an overview of the work we're doing.

Oreboot = Coreboot without C. Oreboot is a fully open-source power-on-reset and romstage firmware written in Rust. By design, the firmware requires all support packages (such as memory init) to be open-source. Currently, Oreboot can boot an AST2500 ARM BMC to Linux with a u-bmc user-mode.

Oreboot rethinks the firmware driver models. Each driver is distilled to four basic functions: init, pread, pwrite and shutdown. This interface allows us to make convenient higher-level drivers such as a "union driver" which duplicates a single write operation to multiple drivers. This makes consoles which have multiple underlying UART drivers elegant.

By using the Rust programming language, Oreboot has a leg-up in terms of security and reliability compared to contemporary firmware written in C or assembly. Rust's borrow-checker ensures pointers are not used after being freed and proves that coroutines are thread-safe at compile time.

In this talk, we will also present a short overview of the basics of Rust, how our driver model incorporates coroutines and the bootflow of Oreboot.

A study on enabling OpenBMC on a high end enterprise Purley server. We take a shipping Lenovo server, SR950 (hw enabled for 96DIMMs / 8CPUs; BMC=Pilot4), and explore readiness of core OpenBMC components when paired with dense configurations. We are interested in boot and runtime performance as well as scaling capabilities such as >256 sensors (use of multi-LUNs).

Progressing of Telemetry framework in OpenBMC given that BMC plays a critical role in ensuring reliability, and serviceability at cloud scale.

Accurate, consistent, and timely telemetry and health monitoring can help in root-causing, mitigating or preventing interruption to ensure high availability.

In this paper, we are going to introduce Static Root of Trust Measurement with
Verified Boot using different mechanisms of SPI flash protection. We shall prove
VBoot great support for coreboot, TPM usage, and cryptographical operations,
and its ability to perform measured and verified boot. We will explain why the Root Key and Recovery Key are the most important components in the VBoot and should be well protected. As a result, we will show a mechanism for automatic decryption of a disk with the assistance of TPM and policies tied to the firmware measurements stored in the TPM.

In a world of a trillion connected devices, Firmware security must be seen as a shared responsibility among all vendors and across different market segments, from Cloud to IoT. TrustedFirmware.org provides a collaborative platform to develop open source reference implementations of Secure world Software & Firmware on the Arm architecture, for both resource-constrained Microcontrollers and powerful Application processors. Moreover, as the architecture progresses and new security features and bespoke platform differentiator factors are deployed, there is an increasingly compelling need for simplification and consolidation of an open-source secure Firmware implementation. Trusted Firmware aims to fulfill that need, by constituting the standard secure basis of all connected devices, encouraging vendors to move their platform specific services into secure sandboxes, and by providing the foundation of the Arm Platform Security Architecture (PSA) Framework.

Sophisticated attackers are targeting system firmware in search of new exploits. Firmware is normally subjected to rigorous integration testing, but how do developers perform more intensive unit testing to reduce errors prior to system integration?
Host-based Firmware Analyzer was recently contributed to TianoCore, an open source community for UEFI development. This is a tool for firmware component analysis with a focus on fuzzing & symbolic testing of firmware components. Host-based methods isolate firmware components in the developer’s OS environment and leverages existing open source analysis tools (ex: AFL, Peach, KLEE).
This session provides an overview of the Linux-based tool and how it is used to improve efficiency of firmware security test cases.

OpenBMC is adding support for the Redfish API. The Redfish API is an open industry standard specification for hardware management. Redfish is defined by the DMTF, Distributed Management Task Force. The OpenBMC 2.7 release has Redfish support for firmware update, inventory, sensors, user management, and event logs. Additional Redfish support will be in the 2.8 release, scheduled for February 2020.

The Slim Bootloader was launched publicly in OSFC2018. Since then, it has attracted public interest and gaining momentum in adoption from the open-source community. The team at Intel continues to make improvements, enhancements & new features to Slim Bootloader over the year and this presentation will provide a summary of what has changed and the key learnings we’ve obtained. This session will also share on the future plans for Slim Bootloader and what’s to be expected.

The coreboot ramstage was created because Linux could not correctly a PCI bus in
1999.
Since then, the ramstage has grown in complexity and, in conjunction with depth
charge, is well on the way to becoming a small kernel.
At the 2018 OSFC Minnich[?] suggested that we might consider making the ramstage optional, since he had found that some im some ports (RISCV) and some situations
(linuxboot) it was no longer needed, and it was a significant burden in terms of boot speed
and code.
Intel and Google have been studying this idea. In this talk we discuss our exploration
into making the ramstage optional. There is a significant boot time performance improvement.

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.

BMCs generally come with protocols such as IPMI, is monitored via SNMP, and uses classical password authentication. What if we consider that these rules can be bent and broken?

Enter u-bmc, a spiritual adoption of LinuxBoot but for your BMC. We will look at what a normal BMC consists of and why that's a problem, what u-bmc can do to help with that, and what we can improve on in the future to help the industry move forward.

Slim Bootloader is an open-source boot solution designed for Internet of Things use cases that requires fast boot speed, built-in security and extensible configuration running on Intel x86 architecture. It leverages the Intel FSP as well as libraries from the EDK2 framework to perform board level configuration and SoC initialization. By default it comes out of the box with an OSLoader payload to perform Linux boot logic as well as a firmware update capable payload to perform the updates in securely and safely methodology. This presentation will walk you through the steps required to port Slim Bootloader for your mainboard with supported Intel SoC using Intel FSP and booting an operating system in both secure and non-secure settings.

It’s common for projects, especially open source projects, to have poor onboarding documentation for new developers, even if other reference documentation is good. This can present a barrier to entry for those interested in contributing to an open project, especially in firmware, which is already relatively inaccessible to many software developers. The talk will discuss strategies for new contributors around writing tutorial documentation which did not previously exist as a method of onboarding. By contributing developer-oriented tutorials early on (the “explain to a novice” method of learning), new contributors can learn about the project at a deep level. The tutorials they create will then speed the onboarding of even more new contributors later on, improving the documentation health of the project and smoothing the learning curve. Inspired by the author’s experience bootstrapping as a developer on the Git project; the talk will include examples and tips for contributors interested in learning for themselves by writing new documentation for any project.

As the OpenBMC kernel maintainer, in this talk I will share with the community the efforts over the past year in upstreaming BMC kernel support.

This talk will cover the development process, the status of the supported BMC system on chips, and what work remains.

It will also discuss work that is coming up over the next few months to enable new machines that various OpenBMC contributors plan to build.

Redfish is an open industry-standard REST API designed for modern and secure management of server hardware. Redfish APIs are implemented in embedded controllers such as the Base Management Controller (BMC) firmware on servers, and are available for IT administrators to remotely and locally monitor and manage their infrastructure using a variety of client applications.

In this talk, we will showcase a number of open source tools and projects available for server hardware and firmware management using Redfish. This includes overview and demo of Redfish support in Ansible, OpenStack, Linux, and Python and Powershell based tools and libraries. We will also describe the open source community efforts in developing these tools, and how you can get involved.

Firmware relies on intimate system knowledge for memory initialization and training. However, there is currently no standard method for passing this data to the operating system. The OS kernel and other monitor software relies on platform-specific drivers, but these are often based on proprietary tables using confidential information.
Intel currently publishes a proprietary BIOS ACPI Data Table (BDAT) to convey system data, such as DDR4/DDR5 training margins. This session proposes moving this data to a format for use by any open source firmware project. The proposed method can be implemented by a complete UEFI stack, or low-level firmware based on PEI driver architecture. This session will also describe next steps for implementation, as well EDK II example code available from TianoCore.

Platform Management Components Intercommunication (PMCI) Working Group defines standards to address “inside the box” communication interfaces between the components of the platform management subsystem. There are some specifications in PMCI that has gained the interest of the OpenBMC community for MC->MC, MC->Devices and MC->BIOS communication. A couple of such protocols are the Platform Management Data Model (PLDM) and the Management Component Transport Protocol (MCTP). MCTP allows for a media independent communications protocol between hardware components. PLDM defines data models and messages for communications related to discovery, sensors, FRUs, monitoring and control, etc, between management controllers and devices. PLDM over MCTP is an alternative over the old standard IPMI over KCS and IPMI over BT.IPMI has a number of open source tools like ipmitool, freeipmi etc. There is no open source tool for PMCI protocols.

This talk will describe the effort for building tooling for PMCI protocols like PLDM,NVMe etc. "pldmtool" is being developed as a requester targeting the PLDM/MCTP stack on OpenBMC. The progress of the development will be described. pldmtool can also be used to target other management controllers implementing pldm. The talk will explain the plans to extend this to support other PMCI protocols like NVMe. The goal is to develop this as a generic reference implementation and share it with the wider firmware community. The talk will cover the proposal to adapt the PMCI tooling infrastructure into a compliance suite.

In this talk we present Fiano, Go-based tools created at Google and Facebook for manipulating UEFI images. Fiano is fast, scriptable, easy to use, and most importantly, does not require you to have UEFI source -- you can modify UEFI ROMs, remove DXEs and, if desired, replace them with a Linux kernel.

Fiano puts you in control of your systems firmware. Even if your BIOS is a blob and outside your control, these tools will help you inspect your firmware (for example, malware analysis) and improve your security.

Fiano can also improve build times, making it possible for individual DXEs to be compiled and inserted into a prebuilt image, avoiding the need to rebuild the entire firmware image.

In the future, we hope to see more systems with a fully open-source firmware stack. Until such time, tools such as Fiano are necessary to give you freedom and act as a stepping stone to bring open-source into your firmware.

NIC continues to be a single point failure for our platforms and this is especially true for multi-host platforms where we have a single Multi-host NIC managed by 1 BMC. On Tioga Pass & Yosemite V2 platform, we have added a user space daemon to monitor and manage NIC through NC-SI. One of its primary responsibility is to monitor link status and performs auto recovery and remediation as needed. We have also been working with NIC vendors on adding OEM NC-SI commands and OEM AENs for our use case. In this talk I will discuss how ncisd monitors NIC status and some of the work we did with NIC vendors to help BMC managing NIC, as well as other command line tools we use in OpenBMC to debug NIC issues.

Binman is a firmware packaging tool.

Modern firmware images can be complex, with dozens of pieces and various alignment and positional requirements. It can be challenging to build these images using a set of ad-hoc scripts and tools which must be maintained.

Binman collects together the files, processes them as needed, handles any other required operations (such as signing entries) and writes out the images. It permits existing images to be inspected.

By placing the image descriptions in a single configuration file, it is easier to inspect and adjust the format and layout. It also improves performance, since images are create in a single pass. Binman supports adding various U-Boot components, lists of files, microcode, binary components, Coreboot Filesystem (CBFS), text and device trees. Binman provides run-time access to the configuration via device tree and linker symbols.

Binman is used in U-Boot to produced binaries for several SoCs, notably Tegra and x86. It has comprehensive tests with 100% code coverage.

This talk describes binman, including a demo of its capabilities.

Processor microcode is akin to processor firmware. Processors may need updates to their microcode to operate correctly. These updates fix bugs/errata that can cause anything from incorrect processing, to code and data corruption, and system lockups. Intel also packages pCode patches (pUnit firmware) along with microcode update. pCode is a critical firmware component for Intel SoC to work correctly. Hence a platform should have the ability to update these firmware in the field.
Post product launch, both the FW patches (together referred to as MCU henceforth) are often updated/released in the field as important fixes are available. Ability to update them in the field helps ensure stability and security of the platform after they are shipped.

Redfish is an open industry-standard REST API designed for modern and secure management of server hardware. Redfish APIs are implemented in embedded controllers such as the Base Management Controller (BMC) firmware on servers, and are available for IT administrators to remotely and locally monitor and manage their infrastructure using a variety of client applications.

This talk is aimed at introducing Snapper, an open source implementation of Redfish API that can be integrated in BMC firmware stacks. In this presentation, we will highlight the Snapper design and implementation, and compare with other Redfish implementations such as OpenBMC bmcweb. The talk will include a demo of Snapper, including simulation environment, and recommendations for community engagement.

This session represents, Bare metal drivers debug on FPGA board starting with Startup code & different controllers(Interrupt Controller,Timer,UART,QSPI) present onboard.
This session describes in detail of controller
Setup,Init,Functionality,Stop,&Shutdown procedure.
This session is useful to understand the FSBL u-boot code (First stage boot loader) in the form of Bare metal drivers & so it is useful in debugging u-boot code in a granular level.
SoC: Xilinx Zynq Zc702 (ARM Cortex A9 Dual core)
Board used: Xilinx FPGA Board (ZED Board)

The U-Boot bootloader has been evolved for nearly 2 decades and is one of the primary and well-known opensource bootloader choice for embedded industry.

The 2019 State of U-Boot development report describe the key updates, features, issues and challenges faced so far on U-Boot community project.

This talk Jagan Teki start with a brief overview of U-Boot community, TPL, SPL, U-Boot Proper, Build process and Startup sequence and then he traverse how different features has been adopted in U-Boot start from the project beginning to most recent versions till 2019. From this traversing he will address the key features like Image boot, FIT, EFI, Secure Boot, DTS, Driver Model, Device Firmware Upgrade, ATF, OP-TEE and etc.

Once giving enough report, he will also talk about steps to port U-Boot to new hardware. Finally, he will address and review ongoing development work, issues and future development on U-Boot community.

Dynamic Tables Framework is a solution to automate and simplify the generation of firmware tables (ACPI & SMBIOS) based on platform hardware description. The goal is to ensure that firmware tables are compliant with relevant specifications. The framework is flexible enough to allow generation of custom OEM-specific tables as well as runtime re-configuration of hardware information described by the firmware tables.
This framework has now been integrated into the Tianocore-edk2 project. This presentation provides an update on the new features that have been added and a summary of the features currently in development. This talk will also cover some interesting use cases where this framework could potentially be used.
The presentation will also discuss new features added to the Acpiview tool. Acpiview allows inspection of ACPI tables from the UEFI shell and can be useful for diagnosing OS boot issues.

This presentation guides the Arm Server System designers towards the common foundation for Server Management. Common manageability capabilities are standardized while allowing scope for value add customization. Server Base Manageability Guide for SBSA Compliant Arm (AARCH64) Servers leverages industry standard system management specifications including but not limited to Redfish, Platform Level Data Model (PLDM), Management Component Transport Protocol (MCTP) as defined by the Distributed Management Task Force (DMTF), Hardware Management Specifications and designs as defined by Open Compute Group (OCP). This presentation will further introduce the audience to manageability capabilities in SBSA Compliant Arm (AARCH64) servers including but not limited to Remote Debug, Reliability, Availability, Serviceability features (RAS), platform monitoring, control and provide status update on Arm Server Base Manageability Guide specification.
Reference implementation will make use of open source projects including but not limited to OpenBMC, Trusted Firmware, U-Boot, UEFI (Tianocore).

The lighting talk introduces the OpenBMC porting on a new OpenPOWER system FP5280G2.
The porting mainly follows the doc add-new-system, and it works smoothly.

Facebook is in the transition to OSF (coreboot/linuxboot) solution as the next generation of host firmware technology. To deploy OSF solution to the fleet, it has to reach feature completeness and maturity. This presentation describes how we set up the build/test infrastructure to support this mission. One design goal of such infrastructure is to ensure effective engineering collaboration with ODMs. Another design goal is to enable the community to build/customize OSF solution on Facebook OCP platform to suite unique needs.

Wiwynn provides Tioga Pass that is one of Wiwynn`s OCP server products and users can develop Linuxboot BIOS for Tioga Pass. And Wiwynn has OSF ready plan for Intel CooperLake platform.

This slide based session provides an overview of Intel’s open source firmware support for upcoming hardware platforms for TianoCore, LinuxBoot, and the OCP Open Source Firmware work stream.

The primary topics are:

OCP Firmware Logo Support - Plans for providing product code and binaries available to meet open development requirements.

Enabling multi-socket servers using Intel® Firmware Support Package (Intel® FSP), including FSP specification and silicon feature support.

Minimum Platform Support – providing open Intel reference board code for use with TianoCore, LinuxBoot, and coreboot.

The session will demonstrate Intel's support for the open firmware community and that that we are on track to make the required Intel collateral available.

This also builds on the discussion of MinPlatform and FSP from Michael Kubacki and Nate Desimone. That is not a necessary prerequisite, but it helps.

PLDM (Platform Level Data Model) Type 5 defines a protocol and a set of commands supporting out of band firmware upgrade. In this talk I will go over PLDM protocol for firmware update, showing a typical upgrade flow, as well as how NC-SI v1.2 has added provisions to carry PLDM traffic over NC-SI/RBT. I will also go over some of the limitation that exists today when running PLDM over NC-SI/RBT, and how this can also support other PLDM types (for example, Type 2, PLDM for sensor monitoring)

Lastly I will discuss what we have currently in OpenBMC codebase to support this feature and provide a sample flow.

The Redfish standard is a suite of specifications that deliver an industry standard protocol providing a RESTful interface for the management of servers.
Redfish also provides the ability to send messages outside the normal request
and response paradigm to clients. The service uses these messages, or events,
to asynchronously notify the client of a state change or error condition,
usually of a time critical nature.

Currently in the bmcweb(openbmc redfish implementation) doesn't have the
eventing support. This talk will describe the effort for building the eventing support in bmcweb.

Two styles of eventing are currently defined by the redfish -
1) push style eventing
2) Server-Sent Events (SSE).

The purpose of the topic is to talk about which approach should be targeted first.
Discuss Merit and demerit of both approach. Security implication of one over other.
How to send the log entry/metric report/normal events through the above listing eventing mechanism?

In this lightning talk I will present a draft proposal for new firmware verification infrastructure in coreboot that has been circulating between Google and Intel. Unlike the existing all-or-nothing one-shot verification, this proposal will hash each CBFS file individually and verify them at time of use. It also contains a plan to move the root of trust into the bootblock and verify every stage from there on out, so that we can tie it to an SoC hardware verification scheme like BootGuard.

When developing or testing firmware on a hardware platform, the developers have to either move flash chips between the target and a programmer, use a target board that is prepared to be used with a flash programmer connected or use an expensive SPI flash emulator instead of the flash chip. For bigger companies and few devices, the latter is quite affordable, but for the other cases, the cost can become a limiting factor.
In this lightning talk, I'll give a short presentation on the qspimux2, which is a small board that sits between the mainboard and the SPI flash, connects to a programmer and makes sure that board and programmer won't interfere when accessing the flash.

The lightning talk will show the current state of coreboot on various Thinkpads.

A comparison to vendor firmware will be given showing missing features in coreboot, features added in the last coreboot releases, as well as possible future tasks.

The SBI interface on linux-on-litex-vexriscv allows us to boot Linux, on a 32-bit vexriscv RISC-V processor, with a few tiny peripherals attached.

This should allow us to run Linux on the smallest 25k LUT FPGAs from Xilinx, or Lattice Semiconductor amongst others.

LinuxBoot is a firmware for modern servers that replaces specific firmware functionality like the UEFI DXE phase with a Linux kernel and runtime. Thus far, LinuxBoot could only launch unix-like OSes via kexec and did not support any OS that relies on the EFI standard. In this session, we demonstrate our proof-of-concept utility that can kexec the Windows EFI loader. The tool is based on the u-root project and modifications to the Linux kexec syscall. We will demo a successful launch of Windows 2019 using LinuxBoot/u-root.

Recent generations of AMD processors implemented in coreboot have firmware based on AMD Generic Encapsulated Software Architecture (AGESA™) version 5.0, also known as Architecture 2008. AGESA v5 was fully compatible with legacy BIOS as well as UEFI, and so it was easily adapted to coreboot using either sanitized open-source versions of the code or a pre-compiled binary. The newer processors with pre-compiled binaries were supported by an integration specification commonly known as BinaryPI.

With the introduction of the “Zen” core, AMD introduced AGESA Version 9. AGESA v9 was designed to optimize building and executing UEFI BIOS. As part of that optimization, support for legacy BIOS was eliminated. This ended compatibility with the previous BinaryPI interface.

In addition, AMD made a number of other changes in hardware which challenge many of the assumptions built into traditional coreboot flow. The largest of these differences being that memory training is completed by an auxiliary processor core before the x86 core is released from reset. This eliminates many of the pre-memory execution constraints assumed in coreboot flow. However, it does not satisfy all of the requirements of initialization normally dealt with during bootblock, vboot and romstage.

A project was undertaken to adapt AGESA v9 to coreboot using the model of Intel® Firmware Support Package 2.0 (FSP). The FSP provided a basic method to support UEFI firmware execution within a coreboot host firmware. While this addresses many of the issues with execution, FSP is also built on assumptions about pre-memory execution and order of operations for Intel processors which are not true for others.

This paper will discuss the solution developed for an AMD Family 17h and associated Mandolin reference board which incorporates Tianocore EDK2 and AGESA v9 into the broadly recognized constructs of coreboot and FSP.

Do you want to have all the tools on your linuxboot system that you have on your desktop, but you can't get them to fit in your tiny flash part? Do you want all your desktop files visible on your linuxboot system, but just remembered there's no disk on your linuxboot system? Are you tired of using scp or wget to move files around? Do you want to run emacs or vim on the linuxboot machine, but know they can't ever fit? What about zsh? How about being able to run commands on your linuxboot machine and have the output appear on your home file system? You say you'd like to make this all work without having to ask your Sysadmin From Hell to Do Magic to your desktop?

Your search is over: cpu is here to answer all your usability needs.

CPU is a go implementation of Plan 9's cpu command. It uses the go ssh package, so all your communications are as secure as ssh. It can be started from /sbin/init or even replace /sbin/init, so you have teeny tiny flash footprint. You can see the code at github.com:u-root/cpu. It's also small: less than 20 files, including tests.

CPU runs as both a client (on your desktop) and an ssh server (on your linuxboot machine). On your desktop, it needs no special privilege. On the linuxboot system, it needs only fusermount. On the remote machine, it mounts a FUSE server into a process private name space at important places like /home/$USER, /bin, and so on. It implements remote file access by relaying FUSE requests via gorpc to a server embedded in the cpu command. The desktop command services those requests; you don't need to run a special external server.

CPU will change your life. You can forget about moving files via scp: once you 'cpu in', the /home directory on your linuxboot node is your home directory. You can cd ~ and see all your files. You can pick any shell you want, since the shell binary comes from your desktop, not flash. You don't have to worry about fitting zsh into flash ever again!

Which OS would you like to run today? With the LinuxBoot playground, you can run a different OS on each boot. Want to run plan9? Just type in "netboot.linuxboot.org/plan9". Want to install ubuntu? Just type "netboot.linuxboot.org/ubuntu.iso". The choice is yours. In this talk, we will cover how we netboot ISO images and security considerations.

Discuss recent coreboot changes for IA platform to perform MP initialization.