The Future of Open-Source Firmware on Server Systems

The Future of Open-Source Firmware on Server SystemsOpen-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 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 Future of Open-Source Firmware on Server Systems
OCP Community Logo - 9element is supporting the OCP as an OCP Community Member
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.
The Future of Open-Source Firmware on Server Systems
Summary Intel Roadmap for Xeon-SP platforms
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!


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.


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.


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! is now Part of LinuxBoot is now Part of LinuxBootWe recently worked on some patches to adopt and integrate it into LinuxBoot - and it got merged now.

So - what is From there website: 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 already has a process in place - so adopting this to u-root only seems logical. It's open-source, that's the idea right? Image Generation Process already has an image processing and generation process in place which we will use to download the images from u-root. is now Part of LinuxBoot
Abstract Image Processing and Generation Process from
All the assets generated by the 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:
    path: /ubuntu-core-19.10/releases/download/19.10-055f9330/
    - initrd
    - vmlinuz
    os: ubuntu
    version: '19.10'
    path: /ubuntu-squash/releases/download/9854741e-b243fefb/
    - 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 menu: is now Part of LinuxBoot menu in u-root
Typing the number of the OS opens the submenu which let's you choose the version of the Operating System you want to boot. is now Part of LinuxBoot
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. 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 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, 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

Converged Security (CBnT) coreboot support and toolingWe 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 we do have our own logo now.
Converged Security (CBnT) coreboot support and tooling
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.
Converged Security (CBnT) coreboot support and tooling
Chain of Trust for Intel CBnT

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.
Converged Security (CBnT) coreboot support and tooling
CBnT Support in coreboot
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.
Converged Security (CBnT) coreboot support and tooling
CBnT Tooling support in coreboot
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: 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!