coreboot Meetings Annoucement And Agenda Call

Dear coreboot community,

Kindly note that the coreboot leadership meeting is scheduled for Wednesday, November 15, 2023 [1].
You are welcome to add things you wish to see addressed during the meeting to the agenda [2].

## Current Agenda Items

### [Martin] Proposal: Agenda items needing a decision must be on the agenda by the time it’s sent
to the mailing list on Monday.
* To give everyone a chance to participate in the decisions being made, we should make sure that
all agenda contains all items being discussed well ahead of time.

I’d propose that we send out an initial agenda calling for any additional items on the Friday
before the meeting, then an updated, final agenda on the Monday before the meeting. (Thank you
Mina!)

We encourage people to update the agenda document before the meeting with any thoughts they have
before the meeting, whether or not they can actually attend the meeting. Posting responses to the
mailing list for the agenda items should also be acceptable - those responses can be collected into
the meeting minutes, at least with a summary and a link.

### [Martin] I’d like to nominate Jérémy Compostella for core developer status.
* Jeremy’s first patch at coreboot was in September of 2016, and he’s definitely done a lot more
recently. CB:16524
He’s volunteered as *the* maintainer for the x86 platform code - no simple task.
He’s shown himself to be extremely capable both in his reviews and in his own patches.
Statistics as of 2023_11_08 - 81 Patches, 93 Reviews, 41 Comments

### [Martin] coreboot 4.22 released this friday.

### [Martin] Change the coreboot versioning from 4.xx to year.month format?
* We’d note this in the 4.22 release notes, and the next release would be 24.02.

### [Benjamin] Add support for calling SMM payloads
* To support UEFI secure boot effectively, we need to perform the verification and SPI write steps
of its variables together, in SMM. Consequently, we need the payload to initialise SMM, and on S3
resume, to relocate these SMBASEs (because the payload is not on the boot path). We would like
approval for this use-case. While this was developed for EDK2, to support secure boot, note that
it’s not UEFI-specific (other potential payloads must have similar design), and contains nothing
specific to secure boot. We are also pursuing future work to share SMM between coreboot and the
payload.

### [Arthur] [A new bootflow on ARM64 server using more of
TF-A](https://mail.coreboot.org/hyperkitty/list/[email protected]/thread/BRW3Z7G5DRYJBOZKAEQV7N7
BAIMXUWM/)
- Reuse working solutions (TF-A) can be a good idea: easier porting.
- The scope of the coreboot side of things is small and very reusable: generating SMBIOS and ACPI
is quite portable between platforms.
- Using only ramstage can be minimally invasive. A similar thing was done to optionally build
romstage sources inside the bootblock: https://review.coreboot.org/c/coreboot/+/55068
- coreboot's security model often relies on it being the first code that executes. This might need
some changes.
- Handoff data from TF-A is often in FDT format for which ramstage has support.
- TF-A is BSD3 licensed. You may not always have access to the source code for your platform.
- Maybe the ease of use and quality of coreboot convinces a more full adoption on server (use only
BL31 like other platforms)? Maybe I'm naive on this?

### [Martin] Localization of non-console strings for coreboot
* With the addition of early display, we’re looking at printing text to the screen directly from
coreboot. Localization is being added for this, but the current patch uses the localization code
from vboot. This isn’t a security related feature so shouldn’t depend on the rest of VBOOT being
enabled.
We also just had an RFC about storing setup engine strings. It seems like we’d want to make sure
that whatever plan we have in place also supports localization for those strings as well.

How do we want to handle localization in coreboot?

### [Martin] Plans for the 4.23 (or 24.02) release
* We’d like to start creating and announcing plans for upcoming releases that the entire project
can work toward. These can be maintenance, new features, documentation goals, or hopefully some of
each.
-[Maintenance] Chipset device trees for all SOCs.

### [Martin] Look at adding Go and Rust to the toolchain
* Go: We’re already using tools written in Go as a part of the build, and they currently use the
system toolchain, leaving droppings outside of the coreboot and $obj folders as a part of the
build. Additionally, we want the binary we produce to be reproducible - I’m not sure if that’s
currently a problem or not. SBOM, STM

Rust: Rust is starting to be used more and more widely as a system programming language. The Linux
kernel is accepting Rust. Oxide’s entire codebase is in Rust. The Oreboot project is using Rust.
While I’m not personally a fan of Rust, I can see the need to support it coming.

[1] https://coreboot.org/calendar.html
[2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit?pli=1
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]