[coreboot] Re: Universal Payload - RFC and Invitation from Universal Payload community

[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]