coreboot

Embracing a New Era: 9elements and AMD Collaborate to Bring Open-Source Firmware to 4th Gen EPYC Server Systems

We are thrilled to announce that 9elements has joined forces with AMD to enable systems using their new 4th Gen EPYC CPUs to run with open-source firmware. This groundbreaking collaboration marks a pivotal milestone in the open-source firmware movement and paves the way for new industry standards. As part of our collaboration, AMD developed a revolutionary library called AMD openSIL, which is responsible for the silicon initialization of their cutting-edge server systems. In contrast to Intel's Firmware Support Package (FSP) - a binary that coreboot calls into - openSIL is open-source and can be directly linked into coreboot. This offers substantial benefits for the open-source community, as they can now build upon and connect to the open-source code directly, rather than relying on unknown binary blobs that lack transparency.

What is AMD openSIL?

Before we dive deeper, let's first clarify what openSIL is. openSIL, or open-source Silicon Initialization Library, is a library designed to enable host firmware solutions to boot modern AMD server platforms seamlessly across the product market segments at scale. AMD's openSIL is committed to becoming entirely open-source and provides an interface for the host firmware to call into, initializing the AMD silicon and booting up as a Proof-of-Concept on 4th Gen AMD EPYC CPU based platforms.

9elements' Involvement

Over the past months, 9elements and AMD have collaborated closely to support AMD openSIL development. In addition, 9elements has assisted AMD in developing a host firmware solution based on coreboot. At the OCP Regional Summit, 9elements will showcase the AMD openSIL demo, where coreboot+AMD openSIL+LinuxBoot boots an AMD EPYC CPU-based platform.

coreboot Support on Modern Server Platforms

This remarkable progress demonstrates the industry's shift towards open-source firmware. In the server market, it is now possible to boot all major SoCs - AMD, Intel, and Ampere - with open-source firmware. While coreboot nowadays support Intel and AMD SoCs, Ampere SoC currently rely on EDKII/TianoCore only. However, Dong Wei, Lead Standards Architect and Fellow at ARM, announced at ByteDance's Cloud FW Event in March that ARM is exploring solutions to have coreboot + LinuxBoot running on ARM-based systems. We anticipate more developments from ARM at the OCP Global Summit and the Open-Source Firmware Conference. In summary, the collaboration between 9elements and AMD represents a monumental development for the open-source firmware movement. The open-sourcing of AMD openSIL and its integration into coreboot will not only benefit AMD and 9elements but the entire open-source community. The shift towards open-source firmware solutions promises to usher in a new era of transparency and security within the industry, and this partnership is a significant stride towards realizing that vision. AMDs announcement: https://community.amd.com/t5/business/empowering-the-industry-with-open-system-firmware-amd-opensil/ba-p/599644

First SBoM Support in Open Source Firmware

The coreboot firmware has just received a new patch adding Software Bill of Materials (SBoM). The SBoM concept has been mainly driven by Richard Hughes and has been derived from an executive order that has been issued last year by the US president. If you are more interested on the background of SBoM, Richard wrote a nice summary here. Summarized, SBoM should provide a way to have a manifest of which parts have been built by whom and from where. The Bill of Materials(BoM) is a common term for hardware developers. It lists exactly what raw materials, sub-assemblies and parts including the quantities of each needed to actually manufacture the product. However, for software this is non-existent. On an operating system level one can sometimes choose on what should go on the disk and what not - for firmware this is not true. Firmware just ships with the hardware you bought - thus you have to live with it (There are exceptions - but in general..)

SBoM is “who built what from where”

SBoM is here to change this and provides a list of used software parts that have been put together. Firmware consists of multiple parts, often lumped together as one binary. Even coreboot, as an open-source firmware projects, has to consume multiple closed-source binaries in order to work properly. Now the end user has an easy way to scroll through the SBoM and check in more detail what really is inside this binary blob called firmware.

How it works

Okay, let's look into more detail how this works in coreboot. Let's jump to the TL;DR first:

coreboot pulls in SBOM templates, modifies those that they fit for needs, and stich them into the image.

With the patchset that adds SBOM, we added three things to coreboot:

First of a set of SBOM templates,
Tooling that converts these SBOM templates into binary format,
Extend the coreboot build system to do all of this automatically while building coreboot.

SBOM Templates

We generated quite some templates for different parts within coreboot. First of all to give everyone a better kickstart in case they want to look at the SBOM files, and probably want to generate them on their own. So let's check how the process looks like if we enable SBOM in coreboot. First of all, the provided patchset adds a new Kconfig to the General Setup menu.

Once enabled, this will generate SBOM files for multiple other components like the Intel Management Engine, or all coreboot payloads like SeaBIOS. Every component gets it's own SBOM file - and can be enabled or disabled separately. For the Intel Management Engine, it looks like this:

If enabled, coreboot takes the provided templates in src/sbom and builds coSWID files out of this. To generate these files, we developed our own tooling called goSWID. The code can be found here, but it will also be checked into coreboot together with the patchset. Within the build log from coreboot, we do see that we have our own sbom CBFS section now.

Details about what the SBOM CBFS section contains, can be printed by the goswid tooling.

The tooling prints in JSON format what the sbom CBFS section contains. It gives you a list of all SBOM files, as shown here for the coreboot SBOM file. Overall the coreboot integration is already quite good - we will improve the experience over time now, however for us it was important to land the change first - and then keep working on the UX. If you have any comments on these changes, feel free to drop us an e-mail.

OSFC 2021 – Going Full Open-Source

OSFC 2020 was a blast - we had great talks and discussions, some virtual beers and a lot of fun - and OSFC 2021 is just around the corner! As remote conferences are new to us (and probably to everyone else as well) we gathered feedback from you - How did you liked the conference and on what bits can we improve to make the experience better next time. Of course, everyone here at the OSFC hoped that we can do a conference in person again - sadly that has to be postponed to next year. So here we are again - going full virtual! The overall feedback from you was good - however there was some feedback on the tools used for the OSFC that we like to share. Our main tool for running the conferences including the ticketing system was hopin.com - even though we liked the overall experience, we also noticed some minor problems around the platform:

The billing and ticketing system was quite simple. We were unable to produce invoices from bought tickets which resulted in us generating invoices manually for each attendee.
We got feedback from various people with different operating systems and browser setups that the stream was not working for them. We tried to resolve as many as possible - however there was not a clear set of which browser does not work on with operating system.
Sometimes the system was rather slow - and the chat was a bit complicated to handle
One big feedback point was that the system was not open - Either accessing the stream directly nor the platform itself was open-source - especially for an open-source conference that's something we put some thoughts in.

With this year's OSFC going virtual again, we put some thoughts into the technology we're planning to use throughout the event. Last time, we were in a rush - flipping everything over from physical to virtual. This year, we took our time and looked into various solution and came up with a plan.

For the conference system itself, we are using Venueless. Venueless is a fairly new system (Initial Commit is from Apr 6, 2020) and it's fully open-source. The code can be checked out on Github. We booked one of the options mentioned on their homepage and added some extra money for features we need for our conference. Even though it's a fairly new project - we have a good feeling with the team and think that will work for us. It's fully customizable and we have a good connection to the developer.

As the ticket system last year was one of the major pain points - we also changed this to pretix. pretix is, again, an open-source ticketing software which can be used obviously for handling tickets - for online, offline or hybrid events. The code can be found on GitHub. If it works out quite well, we're planning to use the system also for future in-person conferences and hackathons again. The system looks good - is more than capable of what we need and we are thrilled to move on with pretix.

Oldie but Goldie - pretalx. Last year we already used pretalx for the Call for Participation for the OSFC 2020 and we also used the schedule functionality and embedded this on the osfc.io homepage. pretalx is also open-source - Github link is here - and we already made some good experience with it. So we are going for pretalx again! Overall - we tried to go as much as possible open-source, and rely on open-source technologies for our conference. We here at OSFC think it's just natural that having a conference on open-source firmware should work with open-source technologies, also for managing and delivering our conference. We do strongly believe in the open-source spirit and support technologies and products build around it.

We hope you liked the new approach we are taking with the OSFC and we try to stick to the open-source spirit as close as possible. Let's see that we all have a great OSFC experience! We are looking forward to build a virtual space for you again - and are looking for great talks and discussion around open-source firmware!

The Future of Open-Source Firmware on Server Systems

Open-Source Firmware for Host Processors is already quite prominent in the embedded world - we do have a lot of systems running on u-boot or nearly every Chromebook which is not older than 5 years is running on coreboot (Surprise, Surprise!). In addition Intel does officially support coreboot and their Firmware Support Package (FSP) in API mode, which is mandatory to be supported in coreboot. So future is looking bright for the embedded world - But what does the server market looks like? Disclaimer: All information have been gathered together through public documents or talks on conferences - none of this information has been officially confirmed by any of the SoC vendors.

The answer is: It depends. It depends on whom you're talking to and which SoC vendor you are talking about.

Intel

Intel announced on the OCP Tech Week 2020 (again), that they will support FSP & coreboot on IceLake platforms and beyond - that means that the new upcoming platform Sapphire Rapids SP will also be supported with coreboot and FSP. Intel made quite a transformation over the latest generations of Xeon-SP platforms. There is a Proof of Concept with coreboot and FSP with Skylake-SP on the two socket server platform OCP Tioga Pass. This landed upstream in the coreboot repositories and is still maintained and functional. However the access to the FSP needed to build the platform is still under NDA and will not be maintained by Intel anymore.

The next step was to enable coreboot on the current generation Cooper Lake. This was done on the OCP Delta Lake server, which is a single socket server running coreboot and FSP. Interestingly, the OCP Delta Lake is the first server to pass the OCP Open System Firmware (OCP OSF) Guidelines which are mandatory now for new platforms to get the OCP Accepted Certification. More information on the OCP OSF initiative can be found online.

On the latest OCP OSF Project Call from April 29th, 2021 AMI, one of the biggest closed-source IBV, stated to get involved in Open-System Firmware. This should give the OSF community even more confidence that Intel holds on their open-source firmware strategy. What a bright future!

ARM

Ampere Computing is a regular guest on the OCP OSF call and presented their LinuxBoot solution on the latest OCP Tech Week 2020. Also Ampere's Arjun Khare presented the latest open-source firmware efforts on the FOSDEM 2021 - by nature ARM always has been more open when it comes to firmware than x86 SoC vendors. Ampere is definitely one of the companies to watch out for in the open-source firmware space. In general ARM is picking up more and more speed in the server world and might be moving into the broader spectrum.

AMD

Even though AMD is heavily involved in open-source firmware on their consumer platforms - nothing is publicly known yet about their efforts to support open-source firmware on server platforms. Our friends from 3mdeb made a presentation at the Fosdem2021 about the current state of OSF on AMD platforms. Bottom line: Nothing is publicly known, however AMD is hiring coreboot developers (mainly for their mobile line) but rumors go around that they're working on something. One main push could have been Ron's presentation on the Open-Source Firmware Conferences 2020 on booting an AMD Rome server board with open-source firmware - This has caught quite some attention. Still AMD has not made any information public - so we need to wait if there is more to come.

TL;DR

Intel is currently one of the top-pushing companies in the open-source firmware space. Also the OCP's Open System Firmware initiative is redefining the boundaries for server systems - overall we do quite some movement in the open-source firmware world - however most of the information is still not publicly confirmed and can only be shared through NDA's. We hope this changes in the future. 9elements does have a good working relationship with various SoC vendors - we specialized on building open-source firmware for scalable server systems and are able to support the newest generations. We are working on a regular basis with OCP and other scalable server systems. If you would like to talk about OSF on a server system - Get in touch with us!

Netboot.xyz is now Part of LinuxBoot

We recently worked on some patches to adopt netboot.xyz and integrate it into LinuxBoot - and it got merged now.

Netboot.xyz

So - what is netboot.xyz? From there website:

netboot.xyz is a way to PXE boot various operating system installers or utilities from one place within the BIOS without the need of having to go retrieve the media to run the tool.

In our last blog article we already pointed out some development work and what motivated us - basically we need a reliable way to install operating systems on machines sitting either somewhere in a rack not accessible for us, or which do not have any external USB ports. Our former way was to build a busybox image which downloads a disk image containing a minimal Linux operation system into the RAM. Once downloaded we would dd the image on a hard drive - and off you go. However that approach needed a lot of manual tooling and adjustment to the current platform we are working on - and netboot.xyz already has a process in place - so adopting this to u-root only seems logical. It's open-source, that's the idea right?

netboot.xyz Image Generation Process

netboot.xyz already has an image processing and generation process in place which we will use to download the images from u-root.

All the assets generated by the netboot.xyz build pipelines are accumulated in one .yaml file which can be found on Github. These endpoints.yaml file does contain kernel, initrd and squashfs locations in the following manner:

ubuntu-19.10-live-kernel:
    path: /ubuntu-core-19.10/releases/download/19.10-055f9330/
    files:
    - initrd
    - vmlinuz
    os: ubuntu
    version: '19.10'
[...]    
ubuntu-19.10-KDE-squash:
    path: /ubuntu-squash/releases/download/9854741e-b243fefb/
    files:
    - filesystem.squashfs
    os: ubuntu
    version: '19.10'
    flavor: KDE
    kernel: ubuntu-19.10-live-kernel

This endpoints.yaml file is used to build the u-root netboot.xyz menu:

Typing the number of the OS opens the submenu which let's you choose the version of the Operating System you want to boot.

Typing in e.g. 07 will boot Debian 10 Core. Be aware - only some major distrobutions have been tested and verified working - Everything in the Other menu can be deemed has experimental and might not work properly.

netboot.xyz provides you a convinent way on how to boot into a live system on your machine. As we are working a lot with server machines where we do not have direct hardware access to, merging netboot.xyz into u-root gives us an easy way to install an operating system on a remote machine during development. If you like to know more about netboot.xyz, check out their homepage. The corresponding code in u-root can be found here. If you like to talk with us about firmware - feel free to contact us!

Converged Security (CBnT) coreboot support and tooling

We are happy to announce that the Converged Security Suite got some major updates and arrived at release version 2.6.0. Not only does this release provide new features, but also comes with a new look! Thanks to the design team at 9elements.com we do have our own logo now.

Some time ago we renamed the TXT-Suite to Converged Security Suite in order to cover more than just Intel Trusted Execution Technology. Now we are making the first step into this direction by releasing the new cbnt-prov tool as part of the 9elements CSS. We here at new 9elements are passionate about security and open-source firmware - and we had the chance to enable Intel Converged Boot Guard and TXT on coreboot-based platforms. Our development platform was the new OCP Deltalake from Facebook, which has been presented on the OCP Virtual Summit 2020.

Intel Converged Boot Guard and TXT

Intel introduced CBnT as an addition to the already present Intel Trusted Execution Technology and Intel Boot Guard. The plan was to merge both technologies together into one - namely CBnT. Intel does rely on so called Authenticated Code Modules (ACMs) which get executed by the CPU, and are signed by Intel - so that only Intel-signed ACMs can run a very specific set of CPUs. Prior to CBnT, there have been two seperate ACMs for either Bootguard or TXT - However with CBnT Intel merged both ACMs together such that there are now two types of ACMs; The Startup ACM and the SINIT ACM. The Startup ACM does establish the Static Root of Trust, where as the SINIT ACM does empower the Dynamic Root of Trust. In the previous version of Intel TXT, the Trust Anchor was the TPM. Intel CBnT moves that Trust Anchor into the Intel Management Engine. In addition, the policies have been defined in the non-volatile part of the TPM, the NVRAM. With Intel CBnT, Intel introduced changes such that you now have two structures to configure Intel CBnT. The first structure is the Key Manifest (KM). The KM closes the gap between Intel Management Engine and Firmware. On one hand, the KM contains a hash of the public key with which the second structure, the Boot Policy Manifest (BPM) has been signed - to validate that only BPMs signed with a certain private key are deemed to be valid. On the other hand, the KM itself is also signed - and the hash of the public key of the KM signing key is burned into the ME.

CBnT-Prov Tooling

The newly introduced cbnt-prov tooling can be used to generate and sign the Key Manifest and the Boot Policy Manifest for Intel CBnT. It can also generate the keys needed for signing the manifests, and stitching them back into the firmware. The cbnt-prov tooling is firmware agnostic - it does not care if you use UEFI or open-source firmware like coreboot. It works with any firmware as long as the firmware respects the Intel CBnT and FIT specification. Extensive Documentation on how to build and use the cbnt-prov tooling can be found here. We do also landed a couple of patches to integrate this tooling directly into the coreboot toolchain, such that one can seamlessly build coreboot with CBnT support enabled - all needed structure can automatically be generated through buildchain - or optionally one can hand in just the binaries. This enables customer to take full control over the CBnT Provisioning process with open-source code - transparent and open.

coreboot Support

As mentioned earlier, we did land a couple of patches to integrate CBnT into coreboot - not only the CBnT Technology itself, but also the KM and BPM can be generated through the toolchain.

In the coreboot > Security menu, one can not enable Intel CBnT Support. Once enabled, the user needs to point to the Startup- and S-ACM location, and needs to define if the KM, BPM should be either generated, optionally signed, or if the user hands in binaries.

Once the user defined KM and BPM options, the coreboot toolchain will build, sign and integrate the KM and BPM structures automatically into the coreboot firmware image - easy!

Why Open-Source Tooling Matters

The Converged Bootguard and TXT (CBnT) Technology is the backbone of your firmware security. It secures what is under your control - the first code that runs on the platform, the so called Initial Boot Block (IBB) and builds up the chain-of-trust for your hardware. Based on the measurements takes by your firmware and the CBnT technology, your security models decides if the machine is trusted or not. And the structures defining those parameters are placed in the KM and the BPM. A wrongly configured KM and BPM can either brick your machine so that your infrastructure does not boot up anymore - or even worse can introduce security flaws which open up an attack window. Thus the owner of the machine should have full control of what should be configured on the machine and even more important have the ability to check what has been configured - to verify the correctness of the applied configuration. These goals can only be achieved through open-source tooling - to give the owner of the hardware full transparency on what has been configured, and the ability to configure the machine to their needs.

Get Involved

The tooling can be found in our repo here: https://github.com/9elements/converged-security-suite/ We are currently working on a CBnT Testsuite and BootGuard Provisioning - so expect more updates here soon! Do you need help with your firmware project? Or want to talk about firmware security with us? Contact us!