Hi
In august FSP2.4 was released with a new feature/component: FSP-I. https://cdrdv2.intel.com/v1/dl/getContent/736809
FSP-I is a blob that initializes SMM and installs a runtime handler and then locks down SMM. Just as a reminder: SMM is a special CPU mode that is entered via a interrupt (SMI) and is completely invisible to the OS. This used to be for power management but now it's often used to avoid writing proper OS drivers e.g. for RAS features.
Extract from section 8: "If an FSP binary provides the FSP-I component, usage of FSP-I can be mandatory for certain processors and chipsets. The Integration Guide will document if FSP-I is mandatory for specific FSP implementations."
By design coreboot has as little runtime as possible. We also dislike blobs, as it's an open source project. Having closed source code inside a CPU mode that is completely opaque to the OS is going against those 2 wishes at the same time + there already exists open source code for setting SMM.
I'd like to start a discussion about not allowing blob runtimes in coreboot before people start writing code to integrate FSP-I. We have had discussions about which blobs are ok and not in the past, with no clear outcome. We don't have a clear policy about what a blob can or cannot do (it only has to be redistributable iirc?), but even without having a clear line of what is ok or not, a runtime blob running on the main CPU is definitely crossing it in my opinion.
What are your thoughts? Do we take a stance against FSP-I integration in coreboot? Are there precedents where blobs runtimes are installed on the main CPU, that I don't know of which could justify FSP-I?
P.S. It's quite sad to see this happen after an open letter 361 people signed for a more open FSP. https://openletter.earth/adopting-open-source-firmware-approach-for-intel-fs...
P.S.2 Not all about FSP2.4 is bad. I like that adds the possibility for 64bit support, though it uses the MSVC ABI instead of SYSV :-( .
Arthur
Hi Arthur, coreboot fellows,
On 30.09.22 13:53, Arthur Heymans wrote:
What are your thoughts?
printing, bonfire...
Do we take a stance against FSP-I integration in coreboot?
I think we already do. From coreboot.org:
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
FSP-I means exactly the opposite of most of the above points. It's inherently incompatible.
IMO, unless we discuss if we want to change how we define coreboot first, there can't be a discussion about integrating FSP-I nor any action in that direction.
Are there precedents where blobs runtimes are installed on the main CPU, that I don't know of which could justify FSP-I?
There's something for the main CPU but definitely not the same: I was told AMD's binary pi can provide runtime ACPI code. But running ACPI is an opt-in for the OS, whilst FSP-I wouldn't even allow an opt-out, I guess.
P.S. It's quite sad to see this happen after an open letter 361 people signed for a more open FSP. https://openletter.earth/adopting-open-source-firmware-approach-for-intel-fs...
Sad, but not unexpected. I believe this is part of a more than a decade old strategy. It seems to me Intel never really supported open-source OS drivers for their server platforms. They just hid everything in SMM with a nice open-source facade for Linux. We turned a blind eye to that. Now it seems that the ecosystem around Intel servers is rather unprepared for open source. Even if they'd open up their SMM code, it would just be wrong to keep the code in SMM, IMO. Proper OS drivers should be written instead.
Nico
note that I am having this exact same problem in the RISC-V community: https://github.com/riscv-non-isa/riscv-sbi-doc/issues/102
People just like their SMM. It's hard to kill.
I fear that you're not going to get much luck with Intel, which is why I try to work with non-Intel CPUs as much as I can nowadays.
On Fri, Sep 30, 2022 at 5:58 AM Nico Huber nico.h@gmx.de wrote:
Hi Arthur, coreboot fellows,
On 30.09.22 13:53, Arthur Heymans wrote:
What are your thoughts?
printing, bonfire...
Do we take a stance against FSP-I integration in coreboot?
I think we already do. From coreboot.org:
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
FSP-I means exactly the opposite of most of the above points. It's inherently incompatible.
IMO, unless we discuss if we want to change how we define coreboot first, there can't be a discussion about integrating FSP-I nor any action in that direction.
Are there precedents where blobs runtimes are installed on the main CPU, that I don't know of which could justify FSP-I?
There's something for the main CPU but definitely not the same: I was told AMD's binary pi can provide runtime ACPI code. But running ACPI is an opt-in for the OS, whilst FSP-I wouldn't even allow an opt-out, I guess.
P.S. It's quite sad to see this happen after an open letter 361 people signed for a more open FSP.
https://openletter.earth/adopting-open-source-firmware-approach-for-intel-fs...
Sad, but not unexpected. I believe this is part of a more than a decade old strategy. It seems to me Intel never really supported open-source OS drivers for their server platforms. They just hid everything in SMM with a nice open-source facade for Linux. We turned a blind eye to that. Now it seems that the ecosystem around Intel servers is rather unprepared for open source. Even if they'd open up their SMM code, it would just be wrong to keep the code in SMM, IMO. Proper OS drivers should be written instead.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi, I would like to invite you to the Universal Scalable Firmware (USF) Community where Intel® FSP is an ingredient to a full system firmware solution and incorporates multiple bootloaders including coreboot. There have been discussions on the updates to Intel® FSP within this community https://universalscalablefirmware.groups.io/g/discussion
What is USF? Links to USF training videos: https://www.youtube.com/playlist?list=PLehYIRQs6PR5N73cbW8CPvU_stDTAG_j5
Thanks, Laurie
Laurie.jarlstrom@intel.commailto:Laurie.jarlstrom@intel.com, System Firmware Products Firmware Ecosystem & Business Dev. (503) 880 5648 Mobile
From: ron minnich rminnich@gmail.com Sent: Friday, September 30, 2022 9:00 AM To: Nico Huber nico.h@gmx.de Cc: Arthur Heymans arthur@aheymans.xyz; coreboot coreboot@coreboot.org Subject: [coreboot] Re: FSP 2.4: runtime blobs!
note that I am having this exact same problem in the RISC-V community: https://github.com/riscv-non-isa/riscv-sbi-doc/issues/102
People just like their SMM. It's hard to kill.
I fear that you're not going to get much luck with Intel, which is why I try to work with non-Intel CPUs as much as I can nowadays.
On Fri, Sep 30, 2022 at 5:58 AM Nico Huber <nico.h@gmx.demailto:nico.h@gmx.de> wrote: Hi Arthur, coreboot fellows,
On 30.09.22 13:53, Arthur Heymans wrote:
What are your thoughts?
printing, bonfire...
Do we take a stance against FSP-I integration in coreboot?
I think we already do. From coreboot.orghttp://coreboot.org:
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
FSP-I means exactly the opposite of most of the above points. It's inherently incompatible.
IMO, unless we discuss if we want to change how we define coreboot first, there can't be a discussion about integrating FSP-I nor any action in that direction.
Are there precedents where blobs runtimes are installed on the main CPU, that I don't know of which could justify FSP-I?
There's something for the main CPU but definitely not the same: I was told AMD's binary pi can provide runtime ACPI code. But running ACPI is an opt-in for the OS, whilst FSP-I wouldn't even allow an opt-out, I guess.
P.S. It's quite sad to see this happen after an open letter 361 people signed for a more open FSP. https://openletter.earth/adopting-open-source-firmware-approach-for-intel-fs...
Sad, but not unexpected. I believe this is part of a more than a decade old strategy. It seems to me Intel never really supported open-source OS drivers for their server platforms. They just hid everything in SMM with a nice open-source facade for Linux. We turned a blind eye to that. Now it seems that the ecosystem around Intel servers is rather unprepared for open source. Even if they'd open up their SMM code, it would just be wrong to keep the code in SMM, IMO. Proper OS drivers should be written instead.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.orgmailto:coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.orgmailto:coreboot-leave@coreboot.org
Hi Laurie
I created a github issue about this https://github.com/UniversalScalableFirmware/documentation/issues/37 almost 11 months ago with no reply. I also don't see any discussions about FSP-I in particular in that community but I posted my github issue again on that mailing list.
Arthur
On Fri, Sep 30, 2022 at 6:45 PM Jarlstrom, Laurie < laurie.jarlstrom@intel.com> wrote:
Hi,
I would like to invite you to the Universal Scalable Firmware (USF) Community where Intel® FSP is an ingredient to a full system firmware solution and incorporates multiple bootloaders including coreboot.
There have been discussions on the updates to Intel® FSP within this community
https://universalscalablefirmware.groups.io/g/discussion
What is USF? Links to USF training videos: https://www.youtube.com/playlist?list=PLehYIRQs6PR5N73cbW8CPvU_stDTAG_j5
Thanks,
*Laurie*
Laurie.jarlstrom@intel.com,
System Firmware Products
Firmware Ecosystem & Business Dev.
(503) 880 5648 Mobile
*From:* ron minnich rminnich@gmail.com *Sent:* Friday, September 30, 2022 9:00 AM *To:* Nico Huber nico.h@gmx.de *Cc:* Arthur Heymans arthur@aheymans.xyz; coreboot < coreboot@coreboot.org> *Subject:* [coreboot] Re: FSP 2.4: runtime blobs!
note that I am having this exact same problem in the RISC-V community: https://github.com/riscv-non-isa/riscv-sbi-doc/issues/102
People just like their SMM. It's hard to kill.
I fear that you're not going to get much luck with Intel, which is why I try to work with non-Intel CPUs as much as I can nowadays.
On Fri, Sep 30, 2022 at 5:58 AM Nico Huber nico.h@gmx.de wrote:
Hi Arthur, coreboot fellows,
On 30.09.22 13:53, Arthur Heymans wrote:
What are your thoughts?
printing, bonfire...
Do we take a stance against FSP-I integration in coreboot?
I think we already do. From coreboot.org:
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
FSP-I means exactly the opposite of most of the above points. It's inherently incompatible.
IMO, unless we discuss if we want to change how we define coreboot first, there can't be a discussion about integrating FSP-I nor any action in that direction.
Are there precedents where blobs runtimes are installed on the main CPU, that I don't know of which could justify FSP-I?
There's something for the main CPU but definitely not the same: I was told AMD's binary pi can provide runtime ACPI code. But running ACPI is an opt-in for the OS, whilst FSP-I wouldn't even allow an opt-out, I guess.
P.S. It's quite sad to see this happen after an open letter 361 people signed for a more open FSP.
https://openletter.earth/adopting-open-source-firmware-approach-for-intel-fs...
Sad, but not unexpected. I believe this is part of a more than a decade old strategy. It seems to me Intel never really supported open-source OS drivers for their server platforms. They just hid everything in SMM with a nice open-source facade for Linux. We turned a blind eye to that. Now it seems that the ecosystem around Intel servers is rather unprepared for open source. Even if they'd open up their SMM code, it would just be wrong to keep the code in SMM, IMO. Proper OS drivers should be written instead.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Laurie, thanks for the invite. If ever a single statement crystallized the problem, this is it: "Intel® FSP is an ingredient to a full system firmware solution and incorporates multiple bootloaders including coreboot."
That's the problem: " incorporates multiple bootloaders including coreboot". With all due respect, this statement displays a lack of understanding of coreboot. coreboot is not a bootloader. Intel keeps wanting to box it in to that role, but that's not what coreboot is or ever was.
coreboot incorporates FSP. FSP provides a support library to coreboot. On Intel, that is. The FSP model is not a desirable solution on other open platforms, particularly ARM, and hence is a point solution for Intel only.
What you are seeing in this discussion is our disappointment in Intel's continuing push to maximize what FSP does, and to minimize what open source code such as coreboot does -- and, further, to Intel's unwillingness to listen.
Even on AMD, the trend (see: 0xide) is to have a full open source stack on the AP. FSP as a model is better than UEFI, but not anywhere near what many Intel customers would like to see. Hence the open letter; hence our disappointment that it seems to have had zero impact on Intel's behavior; hence many companies continuing search for alternatives to Intel products.
I had hopes, with the new CEO in charge, and the statement that Intel was going to change, that Intel would in fact change; now I have only disappointments. At the same time, I'm not at all surprised that nothing has changed. I've been down this road with Intel many times in the last 23 years.
Also, note: from 1999-2005, we had 100% GPL firmware for Intel CPUs, in coreboot (back then, called LinuxBIOS). Why is that not the case today? Because Intel would not allow it.
Thanks
ron
On Fri, Sep 30, 2022 at 10:01 AM Arthur Heymans arthur@aheymans.xyz wrote:
Hi Laurie
I created a github issue about this https://github.com/UniversalScalableFirmware/documentation/issues/37 almost 11 months ago with no reply. I also don't see any discussions about FSP-I in particular in that community but I posted my github issue again on that mailing list.
Arthur
On Fri, Sep 30, 2022 at 6:45 PM Jarlstrom, Laurie < laurie.jarlstrom@intel.com> wrote:
Hi,
I would like to invite you to the Universal Scalable Firmware (USF) Community where Intel® FSP is an ingredient to a full system firmware solution and incorporates multiple bootloaders including coreboot.
There have been discussions on the updates to Intel® FSP within this community
https://universalscalablefirmware.groups.io/g/discussion
What is USF? Links to USF training videos: https://www.youtube.com/playlist?list=PLehYIRQs6PR5N73cbW8CPvU_stDTAG_j5
Thanks,
*Laurie*
Laurie.jarlstrom@intel.com,
System Firmware Products
Firmware Ecosystem & Business Dev.
(503) 880 5648 Mobile
*From:* ron minnich rminnich@gmail.com *Sent:* Friday, September 30, 2022 9:00 AM *To:* Nico Huber nico.h@gmx.de *Cc:* Arthur Heymans arthur@aheymans.xyz; coreboot < coreboot@coreboot.org> *Subject:* [coreboot] Re: FSP 2.4: runtime blobs!
note that I am having this exact same problem in the RISC-V community: https://github.com/riscv-non-isa/riscv-sbi-doc/issues/102
People just like their SMM. It's hard to kill.
I fear that you're not going to get much luck with Intel, which is why I try to work with non-Intel CPUs as much as I can nowadays.
On Fri, Sep 30, 2022 at 5:58 AM Nico Huber nico.h@gmx.de wrote:
Hi Arthur, coreboot fellows,
On 30.09.22 13:53, Arthur Heymans wrote:
What are your thoughts?
printing, bonfire...
Do we take a stance against FSP-I integration in coreboot?
I think we already do. From coreboot.org:
"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology."
FSP-I means exactly the opposite of most of the above points. It's inherently incompatible.
IMO, unless we discuss if we want to change how we define coreboot first, there can't be a discussion about integrating FSP-I nor any action in that direction.
Are there precedents where blobs runtimes are installed on the main CPU, that I don't know of which could justify FSP-I?
There's something for the main CPU but definitely not the same: I was told AMD's binary pi can provide runtime ACPI code. But running ACPI is an opt-in for the OS, whilst FSP-I wouldn't even allow an opt-out, I guess.
P.S. It's quite sad to see this happen after an open letter 361 people signed for a more open FSP.
https://openletter.earth/adopting-open-source-firmware-approach-for-intel-fs...
Sad, but not unexpected. I believe this is part of a more than a decade old strategy. It seems to me Intel never really supported open-source OS drivers for their server platforms. They just hid everything in SMM with a nice open-source facade for Linux. We turned a blind eye to that. Now it seems that the ecosystem around Intel servers is rather unprepared for open source. Even if they'd open up their SMM code, it would just be wrong to keep the code in SMM, IMO. Proper OS drivers should be written instead.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Arthur Heymans -
Jarlstrom, Laurie -
Nico Huber -
ron minnich