2020 OCP Virtual Summit

As the Open System Firmware (OSF) workstream progresses towards enabling redistributable firmware images for OCP hardware, there are key dependencies on Intel. This session is designed to communicate Intel’s progress supporting OSF logo efforts.

At the 2019 Global Summit, OSF built a basic roadmap for OSF logo and OSF has been executing to that roadmap. This update at the 2020 Global Summit is key for ODM and OEM customers planning OSF ready systems.

This session includes updates on open source bootloader enabling and redistributable initialization binaries required for the next generation Intel silicon, including the Intel® Firmware Support Package and Intel® Server Platform Services.

This presentation provides an overview of the market reality of the boot system firmware on Arm devices and systems. It covers Arm Trusted Firmware, SBBR (UEFI/ACPI) for the standard OSes and hypervisors, and EBBR (UEFI layer on top of uboot) for embedded devices. It also describes how open source firmware can be achieved on these frameworks. In addition, the session will explore LinuxBoot support on Arm server systems.

Discuss HPE’s journey to enable open source firmware on the ProLiant product line. Multiple industry customers and leaders, to be named later, will be involved in the discussion to share the benefits to the industry of such OEM enablement as well as the lowering risks of transitioning with increased maturity of open source projects.

This joint presentation between Wiwynn and Facebook gives an update on coreboot/linuxboot feature development for server. It discusses status/design of some server features needed by server. The plans and challenges are also discussed.

During this panel discussion, various speakers from the morning will weigh into the unique challenges of Open System Firmware.

Ron Minnich is moderating and driving the discussion. Questions will also be open to the floor.
The focus is on the OSF 2021 Transition Schedule with topics including (but not limited to) redistribution of binary blobs, firmware ownership and reusability, and documentation.

Firmware has been growing in size and complexity over the years and has become a rich target for attackers. Firmware is currently a popular topic in security research and we find that our work in OSF overlaps some of the work being done in the OCP Security Working Group.

With data rapidly being added or moved to the cloud, hyperscalers and SMBs alike are facing a massive security challenge and often rely on firmware and tools they have little or no visibility into. We assert that security should not be obscure; it should be open, transparent, and available to all.

Furthermore, the hyperscaler model fundamentally changes the way we view firmware development and the supply chain. As hyperscalers continue to grow it has become increasingly important to ensure control and accountability throughout the server lifecycle starting with design and throughout development, validation, deployment, and eventual decommissioning.

In this talk we will discuss design principles, available features, and will walk through a real example of an open and transparent security solution running with OSF on OCP hardware to show how one can build, measure, and verify the integrity of the firmware running on their system. We will also discuss areas where OCP and industry can help white hat research and development efforts.

Firmware for the majority of the Intel product portfolio is implemented using Unified Extensible Firmware Interface (UEFI) compliant firmware. Historically, UEFI firmware was built with a PC ecosystem mindset; open standards but closed implementations.

The emergence of the cloud has shifted the development of computing systems from large-scale OEMs to individual end users. Accordingly, open standards by themselves are no longer enough, modern implementations must be both open source and standards compliant. The key benefit of firmware standards like UEFI is broad operating system and peripheral compatibility, and the ability to mass deploy a single OS image on virtual machines or bare metal machines without modifying the OS image or the firmware.

This presentation outlines the TianoCore Minimum Platform Architecture (MPA), which Intel designed to facilitate a simplified, modular, and consistent firmware porting process. This makes it easier to produce high quality, open source firmware optimized for cloud systems. The MPA Staged Boot Approach will be introduced, which breaks firmware functionality into two main categories:

1. Minimum components required for authenticated boot.

2. Advanced features as modular components, individually selected and customized for the end user's system.

This session will also cover advanced features that are available today including IPMI, USB 3.0 Debug, SMBIOS, and Networking. The presentation will close with a call for collaboration and information on how to get started.

This joint presentation between Intel and Facebook gives an update on FSP and coreboot for Xeon SP (specifically Skylake Scalable Processor and Copperlake Scalable Processor) .

In this talk we will demonstrate how to enable OpenTitan, an open source silicon Root of Trust (RoT) project (which originally is an dedicated security chip designed for servers), to be enabled in FPGA. This presentation We will also describe how latest innovative boot solution – Oreboot could provides the best infrastructure to support OpenTitan project. Oreboot is a fully open-source power-on-reset and romstage firmware written in Rust, and requires all support packages to be open-sourced by design. 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. Hence OpenTitan and Oreboot are perfectly fitted together as a comprehensive solution to address the OCP standards and industry requirements.

Intel recently has provided Server PCH ME firmware binary under a redistributable license to the edk2-non-osi repository. As some immediately noticed the size of this firmware is significantly smaller (0.5MB) comparing to original Intel® Server Platform Services (SPS) ME firmware size that takes around 3MB on SPI flash. How this was possible and how the functional decomposition was made to support the leaner version of Server PCH ME firmware? How does this align with Open platforms and Intel’s efforts for Open Firmware? This transition triggered detailed analysis that resulted in functional split between multiple server platform components. As a result, the Node Manager power control real-time function was functionally decomposed between various platform components. Same approach was applied to other firmware functions previously available in Server PCH ME firmware like telemetry, PCIe MCTP infrastructure support. As a result Server PCH Ignition firmware is responsible only for HW platform initialization and support for Intel® Bootguard technology. This approach enables us to reduce the size of SPI partition designated for SPS image by 6 times so full redundant PCH Ignition SPI sub-partition fits into 0.5MB.

While server industry is rapidly changing, it has become a real challenge for us to keep the pace to provide full-featured and high-quality system firmware solution to quickly meet customer’s needs. On the other side Linux kernel has a huge development community and it covers many duplicated functions with system firmware. So why not utilize the standard kernel capability to do things that was done by system firmware? LinuxBoot is an open sourced solution targeted for this purpose, and it is gaining momentum among industry players and open source community as they are seeking for the next generation of firmware technology. This presentation describes how Intel’s latest innovative boot solution – Slim Bootloader provides the best infrastructure to support LinuxBoot so as to simplify the boot firmware, and how it fits the OCP standards and industry requirements.

In this talk we present Fiano, Go-based tools created 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.
Fiano has added preliminary support for dealing with more closed souce blobs, such is Intel FSP parsing, and limited Intel ME parsing and size reduction.
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.

ITRenew is selling OCP servers under the Sesame brand, those servers come either with a UEFI BIOS or with LinuxBoot.
The LinuxBoot project is pushing the Linux kernel inside bios flash and using userland programs as bootloader.

To achieve quality on our software stack, as any project, we need to test it.
Traditional BIOS are tested by hand, this is 2020 we need to do it automatically!
We already presented the hardware setup behind the LinuxBoot CI, this talk will focus on the software.

We use u-root for our userland bootloader; this software is written in Go so we naturally choose to use Go for our testing too.
We will present how we are using and extending the Go native test framework `go test` for testing embedded systems (serial console) and improving the report format for integration to a CI.

With LinuxBoot we became vendors of our own system firmware. In order to go to production we need a reliable quality assurance process, and firmware testing was a necessity. In this talk we are presenting ConTest (short for Continuous Testing), a modular framework aimed at automating system testing workflows, like firmware validation and provisioning. ConTest has several goals in mind: being open source and community-driven; validate as much as possible at compile time and at job submission time, to minimize unnecessary operations and run-time failures; being lightweight and infrastructure-agnostic, so it can run in Facebook’s datacenters as well as on a Raspberry Pi; being composable, thanks to an interface-and-plugins architecture; being user-oriented so that it’s not necessary to know the internals to use it effectively; and being metrics and events driven, so that users can gain valuable insights about their jobs, more than just success rate (e.g. micro-benchmarking and trend analysis).

ConTest is aimed at anyone who need to automate system-level testing. Various plugins are provided out of the box, with examples on how to use them. The users can combine them like building blocks using a simple job description format based on JSON, and test scenarios of variable complexity. When default plugins are not enough, for example in order to talk to a custom service, users can develop new plugins, and plug them just like if they were part of the core framework. Open-sourcing your own plugins is always appreciated!