Hi
I would like to add a few notes to the meeting notes to clarify things a bit better.
* In the coreboot meeting, it was suggested that we push to just use
coreboot tables as they’re already supported in a number of payloads. This really isn’t practical however. Intel would need to be able to modify the list of known cbmem IDs and they would need to be able to change the description format to something that’s more self-describing.
CBMEM is an internal in memory database that coreboot uses. Payloads don't need to know cbmem and most actually don't. The handoff structure to payloads are 'coreboot tables'. These are far older than cbmem. Inside the coreboot tree those are even still called 'lb_table', so it dates back from when the project was called LinuxBIOS.
'really isn't practical' is a very relative term here... Monday I asked what existing firmware payloads (fwiw this is really a coreboot concept to begin with) don't support coreboot tables that would benefit from having a 'universal' self describing handoff. The answer is none: all existing firmware payloads support coreboot tables. So the only thing not 'practical' here is that UEFI teams don't have control over the handoff structure format that is inside coreboot and is used by coreboot payloads (coreboot tables). The proposed solution is a new format that all payloads and coreboot ought to support. Needless to say that this is a lot of work (adapting both coreboot and all existing payloads) with very little benefits for coreboot.
The current payload handoff method has a number of flaws that
they’d like to fix, such as the address for stack being hardcoded.
Normally payloads set up their own stack very early on so this is not a problem. The context here, was that I voiced some practical concerns about using CBOR as a handoff structure. LinuxBIOS or coreboot tables were carefully designed to be very easy to parse. In fact so easy to parse that Linux payloads on x86 are loaded the following way: - cbfstool has an assembly written trampoline (~150LOC) that parses the coreboot tables and fills in the zero page of Linux - This trampoline is position independent and stackless for maximum flexibility - cbfstool appends this trampoline to Linux payloads inside cbfs - This is done so that coreboots runtime only knows how to load the 'SELF' format (simple ELF) which abstracts all the complexities of payload formats away at buidtime (cbfstool). This is also how other formats are handled (elf, raw bin, FV, ...)
My objection to a new format like cbor was that it is likely very hard to parse using the same trampoline scheme. It is likely possible to write a trampoline using a stack in C, but then again that just complicates things a lot needlessly just to adopt a new format with probably little to gain.
* The coreboot project can, however, encapsulate a CBOR-based
handoff-structure into cbmem, similar to what we currently do with ACPI tables.
I think this is about supporting both a CBOR-based handoff and coreboot tables at the same time. My concerns here are that is requires some synchronization between both codepaths and just increases maintenance in general. Introducing multiple codepaths to do roughly the same is an error we get bit by way too often. I think we should be careful about this...
Additionally Intel was willing to look at using CBOR structures as
input and output to the FSP, so we could get rid of both the UPDs & HOBs.
This seems like the real positive upshot of that conversation!
Kind regards Arthur
On Tue, Mar 29, 2022 at 9:03 PM coreboot org coreboot.org@gmail.com wrote:
# 2022-03-29 - coreboot UEFI working group Next meeting: 2022-04-26
## Attendees: Jay, Werner, Martin, Sheng, Ron, David
## Minutes:
In the coreboot meeting last week, we discussed a proposal from Intel to change the handoff mechanism to payloads [1]. After that discussion, the decision was made to move further discussion of that topic over to the UEFI working group meeting. There was another meeting on Monday, March 28th where we got a much better understanding of what’s going on and the reasons behind the proposal.
- Intel wants to look at modifying the payload handoff as a part of their universal-scalable-firmware [2] initiative.
The current payload handoff method has a number of flaws that they’d like to fix, such as the address for stack being hardcoded.
This likely also gives coreboot an opportunity to address other parts of the USF spec that cause issues or incompatibilities for us.
- The coreboot project got involved when Sheng suggested to Intel that it would be good to align the payload-handoff format with other projects such as coreboot.
Thanks Sheng!
- Using CBOR is the current proposal, but Intel was open to discussing different formats than CBOR if anyone has a better suggestion.
If anyone is not familiar with CBOR, you can get more information at cbor.io [3].
- In the coreboot meeting, it was suggested that we push to just use coreboot tables as they’re already supported in a number of payloads. This really isn’t practical however. Intel would need to be able to modify the list of known cbmem IDs and they would need to be able to change the description format to something that’s more self-describing.
- The coreboot project can, however, encapsulate a CBOR-based handoff-structure into cbmem, similar to what we currently do with ACPI tables.
- Additionally Intel was willing to look at using CBOR structures as input and output to the FSP, so we could get rid of both the UPDs & HOBs.
- The coreboot community can help to drive this, and Intel has said that they will send an email to the coreboot mailing list.
- Since this is a part of the Universal-Scalable-Firmware initiative, it would be good to look that over for issues as well. Currently, it’s very Intel oriented, and specifies that the FSP will be used as the silicon initialization layer, which obviously doesn’t work for non-x86 platforms.
- The details for the weekly meeting are below.
Self Describing Blob discussion.
A copy of this meeting has been added to the coreboot calendar [4].
Biweekly on Monday, 4:00 – 5:00pm CET/CEST Berlin (Currently UTC+2) Video call link: https://meet.google.com/gha-shza-wnw Or dial: (DE) +49 30 300195187 PIN: 848 847 031# More phone numbers: https://tel.meet/gha-shza-wnw?pin=2380921555764 Self Describing Blob discussion Meeting minutes [5].Sean Rhodes from StarLabs has worked to get all of the coreboot related EDK2 patches submitted to their repo. These are still currently in review.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org