Universal Payload - RFC and Invitation from Universal Payload community

[Banik, Subrata]

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

[Peter Stuge]

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

[Banik, Subrata]

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  
Sent: Thursday, November 5, 2020 4:54 AM
To: coreboot 
Cc: Banik, Subrata ; Zimmer, Vincent ; Ma, Maurice ; Sripathi, Srinivas ; Manigandan, Balaji 
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

[ron minnich]

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  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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Zimmer, Vincent]

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 
Sent: Thursday, November 5, 2020 10:55 AM
To: Banik, Subrata 
Cc: coreboot ; Zimmer, Vincent ; Ma, Maurice ; Sripathi, Srinivas ; Manigandan, Balaji 
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  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 -- [e-mail]
> To unsubscribe send an email to [e-mail]