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 <[email protected]> Sent: Thursday, November 5, 2020 4:54 AM To: coreboot <[email protected]> Cc: Banik, Subrata <[email protected]>; Zimmer, Vincent <[email protected]>; Ma, Maurice <[email protected]>; Sripathi, Srinivas <[email protected]>; Manigandan, Balaji <[email protected]> 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 _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
