FSP-I and Open-Source System Management Mode Hardware Certification Requirement

Reading Qubes Hardware Certification Requirements bolded stick out to me.

“Another important requirement is that Qubes-certified hardware should run only open-source boot firmware (aka “the BIOS”), such as coreboot. The only exception is the use of (properly authenticated) CPU-vendor-provided blobs for silicon and memory initialization (see Intel FSP) as well as other internal operations (see Intel ME). However, we specifically require all code used for and dealing with the System Management Mode (SMM) to be open-source.

Recently saw FSP loading SMM · Issue #37 · UniversalScalableFirmware/documentation · GitHub and [coreboot] FSP 2.4: runtime blobs! - coreboot - mail.coreboot.org which lead me to believe FSP-I will increase hardware requiring SMM loading from closed-source FSP. Do I understand correctly? Is this worth discussing?

1 Like

Thank you @Confused to bring that specific problem into a separate thread.

@adw @michael @marmarek?

The whole thread is important there : FSP 2.4: runtime blobs! - coreboot - mail.coreboot.org

1 Like

Indeed, it looks like FSP-I is fundamentally incompatible with our requirements.


:star_struck: Thank you both.

How can I learn more how requirement came about? Any pointers to find past discussions or suggested reading?

You might be able to find some historical discussions by searching the mailing list archives.

1 Like

Thank You.

mail-archive search summary

So far searched using




Feel like using dictionary without knowing spelling. Any more pointers? I will dig more and update when find and understand more.

FWIW my opinion is hardware certification rationale for open-source SMM requirement is not easy to discover (at least for me :smile: ).

Did find this :arrow_heading_down: qubes-users discussion thought provoking and possibly relevant.

@tasket in qubes-users post say
“The biggest problem I see is peoples’ willingness to go along with what is becoming a tradition of anti-competition. Whatever logical fallacies are put forward to make it seem palatable with CPUs will also undermine user motivations in other areas.”

and in followup say
“TBH, I’m not exactly sure why, from a consumer standpoint, open firmware must be a prerequisite when the hardware itself is closed.”

@Insurgo responds
“Because the firmware controls the hardware until open source hardware exists altogether.”

“And the question that arises is: What is Open Source Firmware nowadays?”

tasket reply includes
"Open firmware is becoming more of a long-term goal that we can acheive alongside open hardware. Clearly its not working out too well with closed hardware, and the closed firmware might as well be considered a part of the hardware, IMO. "

Not want to misrepresent other’s idea so mentioning.

My conclusion: Understanding hardware tradeoffs is hard.
Assumption: Creating Qubes hardware certification requirements is even harder.


Which is exactly why it mustn’t be abandoned as a principle (base premise, I don’t know what would be the proper term in English)!

1 Like