What CSP Servers Need from Open Source Firmware Solutions

Since the creation of LinuxBIOS in 1999, open-source firmware (OSF) solutions have increased its footprint first in HPC and Linux-based mission-critical applications, to now many general-purpose compute platforms, such as networking servers, industrial embedded controllers, to client devices. Notably, Chromebook and a few Cloud-based servers, are quite successful products today. Despite its success, Cloud Service Providers (CSP) are mostly on the sideline even though they have the best usage cases for OSF solutions. Why is OSF good for CSP? For one reason, these hosts are more like embedded systems than traditional servers because once they enter data centers, the servers are not open for expansion of modification. As there is no expansion possibility, there is no need for plug-and-play capability, no driver dependency algorithm needed, some even disable USB and any external ports, and there is no need to upgrade memory, PCI devices, or CPUs beyond typical repairing jobs. Since security is the number one focus of CSP, the smaller the size of the source code, the more secured it is. Over the years, many enthusiastic developers are watching the development of OSF, but they see the community lacking of focus on the right things for CSP. In this talk, the speaker is going to go over these areas and share what the optimal OSF features are for CSP.

There have been a couple significant firmware evolutions in x86 PC/server spaces from assembly language to C, from monolithic thread to a dependency-based driver loading algorithm, and AGESA, FSP to aid the developers who do not have access to privileged information. Amazon AWS firmware teams have been paying attention to and experimenting these ideas since its formation in 2016. AWS did a few pathfinding projects, and some of them were shared with OSF community in the past events, such as using SeaBIOS as CSM on real hardware (with contribution back to the community), and a TinyLinux in BIOS leveraging LinuxBoot initiative. We have successfully booted to OS on several internal platforms, but we did not deploy the solution. Why? In this talk, we are going to discuss some of the reasons, and we like to collaborate with the OSF community to advance CSP-focused system firmware solutions with simplicity, modularity, and security in mind.