Universal Payload - RFC and Invitation from Universal Payload community
HI All, coreboot is a modular design with hardware initialization stage followed by a payload to boot OS https://doc.coreboot.org/payloads.html There is a new initiative to standardize the bootloader to payload interface. The initiative is called Universal Payload project and details can be found @ https://github.com/universalpayload/Introduction The goal for this initiative is interoperability between bootloaders and payloads so that different bootloaders can work with different payloads. An early draft of the spec can be found @ https://universalpayload.github.io/documentation/spec/spec.html. The Universal Payload community welcomes feedback and contributions. We are developing various POC codes to demonstrate the concept. One POC uses coreboot as the bootloader and EDKII UEFI as the payload https://github.com/universalpayload/coreboot/tree/universal_payload Thanks, Subrata
Hello Intel, TL;DR: I consider this spec and project an insult to the coreboot project. It is ridiculous and a waste of everyone's time. You seem to completely miss the point of, or ignore, numerous design decisions made in coreboot for very good reasons. I'm not sure which is worse. It seems that you are only able to think in terms of UEFI and ecosystem partner requirements, in which case you should please take that nonsense somewhere else. Long response: Banik, Subrata wrote:
There is a new initiative to standardize the bootloader to payload interface. The initiative is called Universal Payload project and details can be found @ https://github.com/universalpayload/Introduction .. An early draft of the spec can be found @ https://universalpayload.github.io/documentation/spec/spec.html.
The Universal Payload community welcomes feedback and contributions.
In the draft spec you appropriate the payload concept and terminology established by coreboot, and make it sound like payloads somehow originate from your project. While it is flattering that you recognize payloads as introduced by coreboot (actually LinuxBIOS) long before EFI to be a good idea, you still need to be honest in your communication if you want any chance at gaining a good reputation for your project. The draft spec consistently pushes EDK2 over all alternatives and it also pushes as many UEFI-related and legacy concepts (HOBs, ACPI, etc.) as possible. Such behavior is directly contrary to acceptable practice in open projects like coreboot, in fact this tactic that you have chosen looks more like a propaganda campaign in a political fight, it is utterly ridiculous to me. The spec makes very broad statements such as this: "Payloads are considered part of system firmware" But that is not at all true for coreboot, where it is a conscious design decision to have very strong separation between hardware init and payload. Payloads are explicitly *not* part of the system "firmware" - but are an entity of their own, running after coreboot. You confuse Linux as a payload with LinuxBoot in the draft spec. Those flows are two distinct and very different methods to boot into Linux. In the section "coreboot Payload Interface" you pose this question: "How to fill the gap with current coreboot and payload requirement?" The question refers to a "gap" and a "requirement" while the spec does not say what those are. Even though this question is completely unspecific, and thus does not communicate anything useful, the draft spec does not fail to provide an answer, which has the side effect of making the purpose of your project absolutely clear: "Use a library in coreboot to convert the new interface." You want to add "new interface" (as in UEFI-based) stuff to coreboot (and surely any other relevant firmware project) because you are obviously trying to force a new payload interface onto coreboot, instead of adapting to what coreboot already supports. Further, the draft spec in the "Payload principle" section introduces a campaign aimed at retarding firmware back to the BIOS era. "Open: Should Payload return back to bootloader if payload fail? Answer: No for first generation. No callbacks into payload launcher." This explains that you intend to create a callback interface from the payload to the hardware initialization in a *later* version of the spec, doubling down on your serious mistake in EFI to couple all stages together in complicated ways, and ignoring that a callback interface is something that the coreboot project explicitly and purposely rejects, and does not want to see as part of its payload interface. Following that, the draft spec attacks coreboot's established security model, aiming to move security relevant functionality from coreboot to your proposed type of payload: "Open: How to support SMM for booloader and Payload? Where is trust boundary. Answer: SMM should be either part of the payload for present generation Management Mode (MM) PI drivers, but longer term the EDKII PI independent MM modules should be used." Currently coreboot implements SMM, indeed with completely open source code made available under a freedom-ensuring license, and because of the importance of SMM on modern Intel platforms I think that this is actually a large reason for coreboot's success. Your draft spec clearly describes how you want to remove SMM from coreboot and replace it with EDK2 MM drivers in the future. This is just ridiculous. Then we come to the "Security" section of your draft spec: "Today the payload is provisioned as part of the platform initialization code. As such, the payload is protected and updated by the platform manufacturer (PM). The payload should be covered by a digital signature generated by the PM. The platform owner (PO) should not be able to update the payload independently of the PM." This is outrageous, but at least Intel shows its true colours here. We knew from previous publications that Intel does not work in the interest of end users (the platform owners, who *OWN* the platform, it's literally *THEIR* property) but I guess it's nice to see you confirm this once again. You should know that your intent of robbing platform owners of the right to use their own property as they please will always have to face hostility from community-driven projects. This is an obnoxious attempt to restrict platform owners. In the section "Payload Image Format" the draft spec proposes to invent a payload image format which seems far less capable than ELF and is ridden with UEFI baggage, instead of just using ELF (or something like SELF) which has a far longer and stronger track record than the .efi file format. "Sometimes, it might be challenges. For example, producing ELF format from a UEFI FV image." What exactly is that challenge? This blanket claim is not substantiated in any way. What research has gone into this topic? What is the problem? Maybe it can be solved, even if you can't do it. That's how community works. In the "Payload Interfaces" section it seems that this whole project is not thought through very well: "Open: will payload be run in S3 path? Suggest skipping payload." If SMM is in your payload, then that payload will likely need to be involved also during resume. The rest of the draft spec mostly harps on about various UEFI or UEFI-derived data structures. I am not interested. Change this project idea of yours right now. Learn the coreboot design and learn how to work with it, instead of trying to push UEFI concepts and UEFI design onto coreboot. If you choose to continue with this idea I don't think that you will have many enthousiastic supporters, unless of course you force them.. Best regards //Peter
HI Peter, First of all I would like to THANK you for your time to share the feedback. I'm grateful to get your feedback at first place. Please consider my apology if this email sounds different and create some communication/understanding error. This email was not for sure meant to insult coreboot projects. And being an active member of coreboot community since several year now, spending so much time with coreboot project, it was never an intent to do such. Rather we are exploring to see how we could avoid the redundant development effort across all IA SoC supported bootloaders (i.e. UEFI based Min Platform, SBL and coreboot) that would benefit IA-coreboot projects as well. Example: customers can switch easily between one payload to another payload based on their platform need, for their firmware solution and underlying firmware should publish unified information across all payload. Happy to see your early feedback and this would be helpful for our early design process. Thanks, Subrata -----Original Message----- From: Peter Stuge <peter@stuge.se> Sent: Thursday, November 5, 2020 4:54 AM To: coreboot <coreboot@coreboot.org> Cc: Banik, Subrata <subrata.banik@intel.com>; Zimmer, Vincent <vincent.zimmer@intel.com>; Ma, Maurice <maurice.ma@intel.com>; Sripathi, Srinivas <srinivas.sripathi@intel.com>; Manigandan, Balaji <balaji.manigandan@intel.com> Subject: Re: [coreboot] Universal Payload - RFC and Invitation from Universal Payload community Hello Intel, TL;DR: I consider this spec and project an insult to the coreboot project. It is ridiculous and a waste of everyone's time. You seem to completely miss the point of, or ignore, numerous design decisions made in coreboot for very good reasons. I'm not sure which is worse. It seems that you are only able to think in terms of UEFI and ecosystem partner requirements, in which case you should please take that nonsense somewhere else. Long response: Banik, Subrata wrote:
There is a new initiative to standardize the bootloader to payload interface. The initiative is called Universal Payload project and details can be found @ https://github.com/universalpayload/Introduction .. An early draft of the spec can be found @ https://universalpayload.github.io/documentation/spec/spec.html.
The Universal Payload community welcomes feedback and contributions.
In the draft spec you appropriate the payload concept and terminology established by coreboot, and make it sound like payloads somehow originate from your project. While it is flattering that you recognize payloads as introduced by coreboot (actually LinuxBIOS) long before EFI to be a good idea, you still need to be honest in your communication if you want any chance at gaining a good reputation for your project. The draft spec consistently pushes EDK2 over all alternatives and it also pushes as many UEFI-related and legacy concepts (HOBs, ACPI, etc.) as possible. Such behavior is directly contrary to acceptable practice in open projects like coreboot, in fact this tactic that you have chosen looks more like a propaganda campaign in a political fight, it is utterly ridiculous to me. The spec makes very broad statements such as this: "Payloads are considered part of system firmware" But that is not at all true for coreboot, where it is a conscious design decision to have very strong separation between hardware init and payload. Payloads are explicitly *not* part of the system "firmware" - but are an entity of their own, running after coreboot. You confuse Linux as a payload with LinuxBoot in the draft spec. Those flows are two distinct and very different methods to boot into Linux. In the section "coreboot Payload Interface" you pose this question: "How to fill the gap with current coreboot and payload requirement?" The question refers to a "gap" and a "requirement" while the spec does not say what those are. Even though this question is completely unspecific, and thus does not communicate anything useful, the draft spec does not fail to provide an answer, which has the side effect of making the purpose of your project absolutely clear: "Use a library in coreboot to convert the new interface." You want to add "new interface" (as in UEFI-based) stuff to coreboot (and surely any other relevant firmware project) because you are obviously trying to force a new payload interface onto coreboot, instead of adapting to what coreboot already supports. Further, the draft spec in the "Payload principle" section introduces a campaign aimed at retarding firmware back to the BIOS era. "Open: Should Payload return back to bootloader if payload fail? Answer: No for first generation. No callbacks into payload launcher." This explains that you intend to create a callback interface from the payload to the hardware initialization in a *later* version of the spec, doubling down on your serious mistake in EFI to couple all stages together in complicated ways, and ignoring that a callback interface is something that the coreboot project explicitly and purposely rejects, and does not want to see as part of its payload interface. Following that, the draft spec attacks coreboot's established security model, aiming to move security relevant functionality from coreboot to your proposed type of payload: "Open: How to support SMM for booloader and Payload? Where is trust boundary. Answer: SMM should be either part of the payload for present generation Management Mode (MM) PI drivers, but longer term the EDKII PI independent MM modules should be used." Currently coreboot implements SMM, indeed with completely open source code made available under a freedom-ensuring license, and because of the importance of SMM on modern Intel platforms I think that this is actually a large reason for coreboot's success. Your draft spec clearly describes how you want to remove SMM from coreboot and replace it with EDK2 MM drivers in the future. This is just ridiculous. Then we come to the "Security" section of your draft spec: "Today the payload is provisioned as part of the platform initialization code. As such, the payload is protected and updated by the platform manufacturer (PM). The payload should be covered by a digital signature generated by the PM. The platform owner (PO) should not be able to update the payload independently of the PM." This is outrageous, but at least Intel shows its true colours here. We knew from previous publications that Intel does not work in the interest of end users (the platform owners, who *OWN* the platform, it's literally *THEIR* property) but I guess it's nice to see you confirm this once again. You should know that your intent of robbing platform owners of the right to use their own property as they please will always have to face hostility from community-driven projects. This is an obnoxious attempt to restrict platform owners. In the section "Payload Image Format" the draft spec proposes to invent a payload image format which seems far less capable than ELF and is ridden with UEFI baggage, instead of just using ELF (or something like SELF) which has a far longer and stronger track record than the .efi file format. "Sometimes, it might be challenges. For example, producing ELF format from a UEFI FV image." What exactly is that challenge? This blanket claim is not substantiated in any way. What research has gone into this topic? What is the problem? Maybe it can be solved, even if you can't do it. That's how community works. In the "Payload Interfaces" section it seems that this whole project is not thought through very well: "Open: will payload be run in S3 path? Suggest skipping payload." If SMM is in your payload, then that payload will likely need to be involved also during resume. The rest of the draft spec mostly harps on about various UEFI or UEFI-derived data structures. I am not interested. Change this project idea of yours right now. Learn the coreboot design and learn how to work with it, instead of trying to push UEFI concepts and UEFI design onto coreboot. If you choose to continue with this idea I don't think that you will have many enthousiastic supporters, unless of course you force them.. Best regards //Peter
Thanks for the note. I think you're going at this somewhat backwards. While this may seem to you to be a universal payload, to many it appears to be "make everybody support UEFI model." As you have seen, this will not be well received. As Peter points out, the coreboot payload model is simple, deliberately, and in that simplicity there has been a lot of thought. As we know, it's far harder to write less code than to write more code. The coreboot model is to pare down functionality to the minimum possible. In the coreboot model, complexity belongs in the payload. In fact, the coreboot payload went through four distinct evolutions before settling on the current model. That was so long ago it is little remembered; one indicator of our success is that the payload model has been unchanged for almost the last 15 years. But a common payload model might be desired. (could we call it common and not universal? universal has a feel of hubris) Were I to do this, I'd start with a survey. What do the different firmware systems do? What is a payload in these systems? What do payloads require of the firmware, and what do they provide? How is data communicated to payloads? Is there value in having multiple payloads, and can payloads return? How are payloads selected? And so on. From there, we could figure out what the limitations of these models are. From there, we could start to talk about common models. A good example for me is the UEFI handoff block. I think the design is fatally flawed, as it is not self-describing data: you have to know what struct was compiled, what pieces were not #ifdef'd out, by what version of what compiler, with what padding and alignment rules, or you can't use the struct. That's not great. So, rather than accepting a HOB as a given, in a standard that may well last 20 years, why not state the goal of having a way to communicate information to a payload, and then work out a good way to do that, and THEN define what a HOB could be. Might you consider restarting this as a true community effort? Unfortunately there is an appearance that Intel is dictating the standard to the rest of us, take it or leave it, and that is going to generate bad feeling. Thanks ron On Mon, Nov 2, 2020 at 2:58 AM Banik, Subrata <subrata.banik@intel.com> wrote:
HI All,
coreboot is a modular design with hardware initialization stage followed by a payload to boot OS https://doc.coreboot.org/payloads.html
There is a new initiative to standardize the bootloader to payload interface. The initiative is called Universal Payload project and details can be found @ https://github.com/universalpayload/Introduction
The goal for this initiative is interoperability between bootloaders and payloads so that different bootloaders can work with different payloads.
An early draft of the spec can be found @ https://universalpayload.github.io/documentation/spec/spec.html.
The Universal Payload community welcomes feedback and contributions.
We are developing various POC codes to demonstrate the concept. One POC uses coreboot as the bootloader and EDKII UEFI as the payload https://github.com/universalpayload/coreboot/tree/universal_payload
Thanks,
Subrata
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Good points Ron. On the name 'universal,' that was not intended to imply some primacy or import of the proposal. It was more of a starting point, versus something like 'standard' or 'interoperable'. Changing to 'common' does feel more reasonable and more closely matches the intent of the effort. We are just exploring how to have a more generic payload interface for different bootloader solutions. And we definitely want to make this a community effort, thus the initial proposal (maybe we should have called it '0.1' versus '0.7' in the draft or just elided a 'version' for these early days) in the open versus drafting some heavy UEFI Forum "engineering change request" that would be lost in the confines of some standards body closed door deliberations. And we included an implementation alongside the proposal to help inform some of the feedback and discussions. Regarding comparisons with other payload-based architectures, we did include coreboot and other mechanisms like multiboot in an attempt to cull some best practices, but a better summary or survey as you noted ahead of the initial proposal would have helped clarify the properties of each. Some of those considerations were lost in the initial proposal verbiage. It makes sense to capture that alternate payload information into the document in order to support these pro/con considerations, such as payload selection, multi-payload support, and data passing that you mention. For example, for data passing, the intent of the proposal includes a key value pair data structure that is invariant of the location in memory, ABI, and ISA to convey information into the next stage. The hand off block was just a starting point to enjoin the community discussion. Happy to evolve to a more sensible data type via community discussions. Since we'd like multiple community support, we started with discussions on the various bootloader mailing lists and targeted Github issues/pr's to engage with different input. Open to having a new purpose-defined mailing list or slack channel if folks think that will help with gathering broader input. And as you note, achieving 'simple' is definitely difficult, so removing/modifying code and content from the proposal would be a win if we can help solve some problems (e.g., getting more payload reuse across bootloaders) for which people see some benefit. Thanks again for the input so far and look forward to more discussions. thanks, Vincent ________________________________ From: ron minnich <rminnich@gmail.com> Sent: Thursday, November 5, 2020 10:55 AM To: Banik, Subrata <subrata.banik@intel.com> Cc: coreboot <coreboot@coreboot.org>; Zimmer, Vincent <vincent.zimmer@intel.com>; Ma, Maurice <maurice.ma@intel.com>; Sripathi, Srinivas <srinivas.sripathi@intel.com>; Manigandan, Balaji <balaji.manigandan@intel.com> Subject: Re: [coreboot] Universal Payload - RFC and Invitation from Universal Payload community Thanks for the note. I think you're going at this somewhat backwards. While this may seem to you to be a universal payload, to many it appears to be "make everybody support UEFI model." As you have seen, this will not be well received. As Peter points out, the coreboot payload model is simple, deliberately, and in that simplicity there has been a lot of thought. As we know, it's far harder to write less code than to write more code. The coreboot model is to pare down functionality to the minimum possible. In the coreboot model, complexity belongs in the payload. In fact, the coreboot payload went through four distinct evolutions before settling on the current model. That was so long ago it is little remembered; one indicator of our success is that the payload model has been unchanged for almost the last 15 years. But a common payload model might be desired. (could we call it common and not universal? universal has a feel of hubris) Were I to do this, I'd start with a survey. What do the different firmware systems do? What is a payload in these systems? What do payloads require of the firmware, and what do they provide? How is data communicated to payloads? Is there value in having multiple payloads, and can payloads return? How are payloads selected? And so on. From there, we could figure out what the limitations of these models are. From there, we could start to talk about common models. A good example for me is the UEFI handoff block. I think the design is fatally flawed, as it is not self-describing data: you have to know what struct was compiled, what pieces were not #ifdef'd out, by what version of what compiler, with what padding and alignment rules, or you can't use the struct. That's not great. So, rather than accepting a HOB as a given, in a standard that may well last 20 years, why not state the goal of having a way to communicate information to a payload, and then work out a good way to do that, and THEN define what a HOB could be. Might you consider restarting this as a true community effort? Unfortunately there is an appearance that Intel is dictating the standard to the rest of us, take it or leave it, and that is going to generate bad feeling. Thanks ron On Mon, Nov 2, 2020 at 2:58 AM Banik, Subrata <subrata.banik@intel.com> wrote:
HI All,
coreboot is a modular design with hardware initialization stage followed by a payload to boot OS https://doc.coreboot.org/payloads.html
There is a new initiative to standardize the bootloader to payload interface. The initiative is called Universal Payload project and details can be found @ https://github.com/universalpayload/Introduction
The goal for this initiative is interoperability between bootloaders and payloads so that different bootloaders can work with different payloads.
An early draft of the spec can be found @ https://universalpayload.github.io/documentation/spec/spec.html.
The Universal Payload community welcomes feedback and contributions.
We are developing various POC codes to demonstrate the concept. One POC uses coreboot as the bootloader and EDKII UEFI as the payload https://github.com/universalpayload/coreboot/tree/universal_payload
Thanks,
Subrata
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
participants (4)
-
Banik, Subrata -
Peter Stuge -
ron minnich -
Zimmer, Vincent