# 2023-11-15 - coreboot Leadership Meeting
## Attendees Martin Roth, Wilhelmina Asante, Matt DeVillier, Maximilian Brune, Tim Crawford, Felix Held, Julius Werner, Jonathan Hall, Nico Huber, Jeremy Compostella , Karthik Ramasubramanian, Felix Singer, Benjamin Doron, David Hendricks, Sergio Moreira, Solomon Alan-Dei, Simon Glass, Lean Sheng Tan.
## Open Action Items * 2023-11-15 * [Open] Martin: Publish coreboot FAQ * [Open] Martin: Make announcement about changing release numbers in the release notes of the final 4.xx release. Following releases will use year.month.sub release format. 24.02 (24.02.00 implied) would go to 24.02.01 if a release update is needed. The next release, 3 months later, would be 24.05. * 2023-11-01 * [Open] Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * 2023-10-18 * [Started] MattD and WernerZ :Work on compiling a list of website requirements from the mailing list. * No feedback yet - Matt will continue to gather feedback. * Probably have all of the community input - Need to capture the requirements as a starting point. * [On hold pending requirements] MartinR & FelixS: Build a POC front page. * [Open] Arthur: Ask Philip about how to use company logos. * [Prototyped] Martin: Create coreboot governance page * Please review and give comments. * 2023-10-4 * [Started] Martin: Write a tutorial for gerrit - Feel free to help. * [Open] OSFF: Look into making a video about using gerrit. * Discussed with Christian who felt this was a good plan. * Look at next year. * [Open] Martin: Write a document about vendorcode submodules. * 2023-09-20 * [Started] Martin: Work on clang-format config update. * We can use the clang format version from the coreboot toolchain! * Some issues with clang format - martin will present. * See CB:78833 for what the current format’s changes will look like. * [David] #defines for bits in headers lose their indenting. Maybe we should have clang-format ignore headers for now. Smaller issues can be handled on a "use your best judgement" basis. * [Done] Martin to add bitfield example to 78833. * Let’s look at running this just for .c files to start with.
## Minutes
### [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. * FelixH: Maybe move the freeze to tuesday? No strong feelings. * Nico: I don’t know that this will really help - Things addressed in the meeting still can’t be discussed on the mailing list. Proposal might help but can also slow things down. * FelixS: Leadership meeting could just become the discussion channel. The meeting shouldn’t be the first place to announce an issue. People should start discussions with a new thread for every issue. * Martin: Do we really need separate email threads about every issue? Can people not read and respond to the agenda? * FelixS: The actual content is hidden in the agenda. Having a separate thread gets people more involved. * FelixH: Agenda being sent out is a huge improvement over what we had before. Not a fan of mailing lists. * Sheng: Agree with not forcing people to write threads - some people prefer talking over writing to the mailing list. * FelixS: Not trying to force anything, but the mailing list reaches more people. * FelixH: The leadership meeting allows people to contribute more easily. * DavidH: We should take input in multiple forms for controversial decisions. Not everything needs to be discussed. We already generally ask to spawn a thread on the mailing list for controversial issues. **Decision: Let’s try the original plan as Martin proposed for now - If there are any decisions that should have been made on the mailing list, please let us know. If there are any issues that need to be worked out, we can look at how the plan needs to be modified.**
### [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. **Decision: No objections, tentatively approved. If there are any objections, please email David, Matt or Werner before Friday.**
### [Martin] coreboot 4.22 to be released this friday. * Felix will send out another email.
### [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. Current number is meaningless. - Matches us up with linux distros. **Decision: We will change the format - Martin to announce in release notes.**
### [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 initialize 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. * Allows enablement of secureboot. * Considered just using smm store as it is - but this just submits the write. Downside can call the SMI. * Considered bringing the entire variable stack into coreboot. EEK! * Following what intel is doing for UPL, enabling payload to install SMM - takes care of its own variable stack. * Don’t init SMM on cold boot. * Passes data in cb tables - (fairly) silicon agnostic (intel specific). - not strictly required) * Can Payload init SMM on its own? * On S3 resume, payload isn’t on resume path. Coreboot would take data saved and trigger an SMI from coreboot so we can continue. * Dammit, looks something like UEFI - just because that’s what’s currently supported - any other solution would need to do something similar. * FelixH: On the AMD SOCs - SOC specific in SMI handler. How would these hook into the payload handler? The payload would need to know about the specifics. Solves one problem, but creates other issues. Makes payload non-hardware agnostic. * Benjamin: User can decide to include and support secureboot or not. Open source currently. * Martin: What prevents hardware vendors from forcing the inclusion of closed source binaries to support their hardware? * Benjamin: Nothing - but the person doing the compile gets to decide. * Sheng: Huge security impact. Currently we can’t do any secureboot. coreboot currently has no way to handle this currently. * Nico: Any other solution would do something similar - is this actually true? We have vboot that does things differently. Have you considered not doing things with SMM. * Benjamin: Vboot covers the boot path, doesn’t cover the final bootloader. * Nico: true, but it could verify the variables when they’re consumed. * Benjamin: The problem is that smm store can’t prevent people from writing. * Nico: If you don’t use SMMstore, there are other possibilities. * Benjamin: can’t call back into vboot * Nico: why would you need to? * Benjamin: Take the concept of vboot and put it into libpayload & the payload. * MattD: What about the effort to share smm between vboot & payload? Can that address some of these issues? * Benjamin: The concerns are more about licensing. About 2 big steps away from being able to test sharing.
### [Martin] Plans for the 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. * MattD: Would be good to have 3-5 big scope items for each release.
### [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 * Can probably drop this for now? * 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. * MattD:Can gather more engagement with support for more popular languages. * MaxB:Is this just about tooling or actually adding code? * MartinR:Toolchain for now, but this would start the direction of accepting rust. *MaxB: How would it look to start adding rust code? * FelixH - doing the SMI handler in rust would be interesting. * Nico: On the matter of integrating different languages - looked at it with ADA, same applies to rust. Would need good interface code. We’d need to create bindings for rust - then we could start creating things like drivers. * Benjamin: Would this be a maintenance issue? Would we need strict rules around languages for specific areas to allow for maintainers for each of the areas? * FelixH: Can we just start with tooling and payloads and see how it goes?
### [Sheng] Winter Hackathon hosted by 9E * November 17th - 19th * So far, ~35 people are planning on attending. * (https://opensourcefirmware.foundation/events/osff-fall-hackathon-2023/)
### [Martin] Fosdem: Open Source Firmware, BMC and Bootloader Room * Call for participation * (https://lists.fosdem.org/pipermail/fosdem/2023q4/003524.html) * Submission Deadline: 11-Dec-2023 @ 23:59:59 UTC * Acceptance Notification: 13-Dec-2023 * Final Schedule Posted: 15-Dec-2023
### [Martin] Syspro servers here, but not set up yet * These will be used for non-critical builds. * Need help setting up BSD server.
## Closed action items * [Done] Martin: Note the slowdown of syncing the master branch to the 4.22 release notes - Updates are now weekly & branch will be removed at 4.23 release. * [Done] PatrickG: Slow down the updates of the master branch. * [Done] Martin: Send out an email to the mailing list about running devicetree.cb files through the C preprocessor to get feedback. * FelixH don’t use a preprocessor. * What problem are we trying to solve? If just adding Kconfig then preprocessor opens up too much. * Julius - Macros are easier to write - sconfig is hard to learn.
# Next meeting * November 15, 2023 * [Meeting link](https://meet.google.com/pyt-newq-rbb) * [coreboot Calendar](https://coreboot.org/calendar.html)
# Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting.
# coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...