3 June 2022
Adopting Open Source Firmware Approach for Intel FSP

Dear Intel,

We have heard you, and we agree with you: “Innovation thrives in an open, democratized environment where people can connect, collaborate, and respond together to new stimuli.…. This free exchange increased our ability to learn from one another.” [1] Under this exact sentiment, we hereby request a pledge from Intel to adopt an open source friendly development approach for silicon firmware delivery.

According to the published technical article by Subrata Banik from Google (Open Source Firmware Development: Reduce Firmware Support Package (FSP) boundary on Intel® SoC Platform) [2], there are imminent and industry-wide demands calling for a more open source approach in the host firmware space. Let’s examine the current situation and define the most feasible path forward.

A decade ago, Intel introduced the Firmware Support Package (FSP), which wraps the proprietary processor and chipset initialization code in a binary PI (platform initialization) model. This enabled any vendor or developer in the world to adopt Intel SoCs freely without the IBV lock-down. Since then, the open source firmware initiative has given birth to many thriving firmware projects like coreboot, U-Boot, LinuxBoot and many; thus creating a healthy firmware ecosystem surrounding x86 architecture and more specifically with Intel architecture.

Over the years though, the FSP has grown significantly, and each new generation has become an increasingly chunky and tightly locked down firmware framework for the various hardware platforms. The ‘one-binary-fits-all’ model not only provides the developers and ecosystem partners with very little to no control over the chip enablement, it also increases platform security risks as more closed code without a chance for a public review has been added in every generation causing the FSP to become more and more bloated. This has unquestionably increased the deployment cost on the partners' side while they work on Intel platforms and has set a very high threshold to enter the Intel ecosystem.

The new “alternative path” model outlined by Subrata creates a very viable and pragmatic approach to get rid of the secrecy in the platform enablement model present in the current approach. It balances the business needs of SoC vendors and protects their core interests while enabling more innovation and allowing participation from the open source community. Here are some of the highlights of the new design philosophy:

The goal of highly integrated firmware can only be achieved if the code that is integrated into coreboot or other firmware packages is available as source code. Every code that is added in binary form during the build contradicts this approach and produces unnecessary tension within the community and between Intel and their partners. Having the source code for as many pieces as possible in the boot flow enables the community to find the most suitable boot solution for all Intel processors directly.This will not only speed up the development but in addition provide high quality and adaptable code doing the initialization right.

Hereby, we call upon Intel to join us and commit once again to the power of an open ecosystem.

[1] linkedin.com/pulse/open-letter-ecosystem-pat-gelsi...

[2] blog.osfw.foundation/osf-intel-reduce-fsp-boundary...

492
signatures
375 verified
  1. Philipp Deppenwiese, CEO, immune GmbH, Bochum
  2. Werner Zeh, Firmware Engineer, Siemens AG, Erlangen
  3. Subrata Banik, Firmware Engg, Google ChromeOS, Bangalore
  4. Christian Walter, Head of Firmware Development, 9elements GmbH, Bochum
  5. Arthur Heymans, Firmware engineer, 9elements, Antwerp
  6. Michał Kopeć, Firmware Developer, 3mdeb, Gdańsk
  7. Michael Larabel, Developer, Editor, Phoronix, Chicago
  8. Lahfa Samy, Cybersecurity apprentice at Rexel, Paris, France
  9. Gauvain Roussel-Tarbouriech, R&D engineer, Khiup Technology / newtype64, Paris
  10. Martin Roth, Firmware Engineer, Google, LLC, Longmont, CO
  11. Sean Rhodes, Engineer, Star Labs, Godalming
  12. Léo Lam
  13. Daniel Maslowski, Software Engineer, Essen
  14. Matt DeVillier, coreboot engineer, Purism SPC, Austin
  15. Johannah Sprinz, Researcher, UBports Foundation, Munich
  16. Michael Niewöhner, Dachau/Munich
  17. Antonio Bonifacio, Software Engenieer, Milano
  18. Daniel Suarez, Student, Boston
  19. Kevin Majewski, Student, Wolfenbüttel
  20. Tobias Schmid, Software Engineer, Oberriet
...
335 more
verified signatures
  1. Shinzo Abe, Politician, Japan, Tokyo
  2. Edward Swierk, System Software Engineer, Volkswagen of America, Inc, Mountain View, CA
  3. Angel Pons, coreboot developer, 9elements Cyber Security
  4. Joseph Sudac, Substitute Teacher, Meridian, ID
  5. Matei Dibu, Developer, Cluj-Napoca
  6. Duncan Vriend
  7. Jason Spencer, Software Develpoer, Nanaimo
  8. Juergen
  9. Alberto Fabbri, Student, Kristianstad
  10. Otto Bolyós, programmer, Slovakia
  11. George Hodgkins, student, University of Colorado, Boulder
  12. David Smith, Tester, Birmingham
  13. Paul Michael Tidwell, Owner, Abraxus industries, cornelius
  14. James Nulty, Engineer, Belfast
  15. Ivan D Vasin, Software Engineer, Boston
  16. Steven Keuchel, Researcher, Vrije Universiteit Brussel, Brussels
  17. Ethan Horger, Software Engineer, Oxford, MI, United States
  18. Frédéric Christ, IT Security Engineer, Paderborn
  19. Dave Taht, Queue Theorist, Bufferbloat.net, Half Moon Bay
  20. Edwin Barczynski, software engineer, Luxoft, Wroclaw
Create an open letter
and sign it together