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/coreboot@coreboot.org/thread/BRW3Z... 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/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...