coreboot February 2024

coreboot@coreboot.org

21 participants
26 discussions

Termin mit Hinweis abgesagt: coreboot Leadership Meeting - Every 2 weeks from 11:00 to 12:00 on Wednesday (MST) (coreboot@coreboot.org)
by coreboot org 11 Feb '24

11 Feb '24

Dieser Termin wurde mit folgendem Hinweis abgesagt: "Updated with link to BigBlueButton meeting space." coreboot Leadership Meeting Every 2 weeks from 11:00 to 12:00 on Wednesday Mountain Time - Denver Standort US-BLD-PEARL2930-1-A-Nine-banded Armadillo (6) [GVC] https://www.google.com/maps/search/US-BLD-PEARL2930-1-A-Nine-banded+Armadil… Mit Google Meet teilnehmen https://meet.google.com/pyt-newq-rbb?hs=224 Per Telefon teilnehmen (US) +1 608-618-4744 PIN: 143813170 Weitere Telefonnummern https://tel.meet/pyt-newq-rbb?pin=6680344120895&hs=0 The meeting will be held via BigBlueButtonhttps://bbb.sfconservancy.org/b/mar-sfn-e22-axicoreboot leadership meeting minutesUse the number and pin below to join the meeting.United States (US): +1-718-247-9666PIN: 89421 Organisator pgeorgi(a)google.com pgeorgi(a)google.com ~~//~~ Einladung von Google Kalender: https://calendar.google.com/calendar/ Sie erhalten diese E-Mail, weil Sie ein Gast des Termins sind. Wenn Sie keine weiteren Informationen zu diesem Termin erhalten möchten, lehnen Sie die Einladung ab. Wenn Sie diese Einladung weiterleiten, kann jeder Empfänger eine Antwort an den Organisator senden und zur Gästeliste hinzugefügt werden. Außerdem könnte er weitere Nutzer einladen und Ihre Antwort ändern. Weitere Informationen https://support.google.com/calendar/answer/37135#forwarding

1 0

[coreboot - Bug #522] (New) `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function.
by Vadim Zaliva 10 Feb '24

10 Feb '24

Issue #522 has been reported by Vadim Zaliva. ---------------------------------------- Bug #522: `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function. https://ticket.coreboot.org/issues/522 * Author: Vadim Zaliva * Status: New * Priority: Normal * Category: coreboot common code * Target version: none * Start date: 2023-12-27 * Affected versions: master ---------------------------------------- `region_overlap()` function checks whether or not two memory regions overlap. Memory regions are represented as a region struct that contains the region's offset and size. This function then relies on `region_end()` function to compute the end of the region. `region_end()` function is susceptible to an integer overflow, which might result in the incorrect behaviour of `region_overlap()` function. An example of inputs that lead to wrong behaviour: ``` struct region r1 = {SIZE_MAX - 10, 20}; struct region r2 = {SIZE_MAX - 20, 15}; ``` It returns 0, but since the regions actually overlap, it should return 1. `region_overlap()` function is used in `smm_region_overlaps_handler()` function, which is itself used in SMI handlers to validate address values that come from an untrusted environment. This is necessary to prevent security vulnerabilities such as described in [BARing the System by Yuriy Bulygin, Oleksandr Bazhaniuk et al.](https://www.c7zero.info/stuff/REConBrussels2017_BARing_the_system.pdf) We do not have an example of an exploit based on this incorrect behaviour and are aware of the existence of one. However, theoretically, this could lead to security vulnerabilities. This bug was found during an ongoing [Coreboot Formal Verification Project](https://zaliva.org/UCSC-Twisted-Presentation-20231211.pdf), which aims to prove some important security properties of the coreboot’s SMI handler for the Gemini Lake/Octopus platform using Coq proof assistant and Verified Software Toolchain framework. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

6 16

2024-02-07 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 08 Feb '24

08 Feb '24

# 2024-02-07 - coreboot Leadership Meeting Minutes ## Attendees Mina Asante, Martin Roth, Felix Singer, Jay Talbott, Werner Zeh, Matt Devillier, Patrick Georgi, Ahmed Elgogary, Jonathan Hall, Felix Held, Nicholas Chin, Simon Glass, Julius Werner, Varshit Panda, David Hendricks, Nico Huber, Lean Sheng Tan, Max Brune. ## Open Action Items * 2024-01-10 * [Open] Werner: Push patch based on https://ticket.coreboot.org/issues/522 * Nico: https://review.coreboot.org/q/topic:enforce_region_api * [Open] Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. * 2023-11-01 * [Started]Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * We can save over 900MB by using shallow submodules. * [Projects & RFCs](https://docs.google.com/document/d/15H2m4swdESSgGaIuINOePkyst8b39Y7Lu…. * Making progress - see email thread. * 2023-10-4 * Martin: Write a tutorial for gerrit - Feel free to help. [Started](https://docs.google.com/document/d/1Z8igNdgBG5_Qlr4kKRtlbpKaZo9RUg…. * [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. ## Minutes ### [Martin/Felix] Switching to BigBlueButton. * The upcoming meeting in two weeks (02/21/24) will take place on BigBlueButton instead of Google Chat. Further information will be published to the mailing list between Wednesday's meeting and the following one. * New meeting link to join the leadership meeting: * https://bbb.sfconservancy.org/b/mar-sfn-e22-axi * For phone access, call +1-718-247-9666, then enter 89421 as the conference PIN number. * It looks like there’s only a USA phone number. ### [FelixS] Building a community FSP for Intel based platforms * Initial coreboot support for Intel consumer platforms mostly comes with Google Chromebooks. * coreboot support for a wide range of mainboards is only possible if Intel releases FSP binaries. For some platforms Intel refuses to release a FSP binary and Intel also refuses to fix issues within FSP. * How to make coreboot more independent? People have tried convincing Intel to make FSP open source. It seems unlikely that anything in that regard happens any time soon. * As a compromise, I am proposing to build our own FSP from scratch that is built by the community, specifically companies. It's still meant to be closed-source, since Intel won't allow us to write open source code, but then we are able to extend and improve it whenever we want. * Will Intel allow us to distribute our own binaries if the code is completely written by ourselves? * Possible issues * Getting a multi-party NDA * [Werner] First of all we need an entity which could be the NDA partner (OSFF could probably be?) * Getting a license so that we are allowed to distribute it * [Werner]The license that comes with the FSP code that I am aware of explicitly inhibits code changes and productive use of self-built binaries. How would we ensure this? * [FelixS] AFAIK the standard license allows us to do code changes but it doesn’t allow us distributing the binary over let’s say a website. So I am wondering if it’s different with something we build ourselves. * [Sheng] Do you have connections with Intel folks to make this happen or initiate the discussion? Is there a solid plan for this, to outline the goals, process, and details with Intel? Or is this just a mere suggestion that is probably not very practical? Since this is not an Intel specific issue, how about AMD? This won't happen overnight - who is going to lead this initiative with Silicon vendors, initiate discussions and meetings (and it will be a difficult and consuming process), collect feedback from all parties, and craft out a solid plan to move ahead? * [Martin] In coreboot’s agreement with SFC, we agreed that any and all software and/or documentation developed and maintained by the Project and the Project’s participants will be distributed solely as Free Software. * Because of this agreement, while this proposed FSP could be interesting to the coreboot group, it’s not, and cannot be, a coreboot project. Since we wouldn’t be able to open source the proposed FSP, I’m not even convinced that it’s something that should be discussed in this meeting. * [Felix S.] Just wants to hear the opinion of the coreboot community and not try to add this project to coreboot’s projects * [Jonathan H] It would be hard to get manager support since it’s not open source. * [Jay T] A separate license is required for release. The FSP needs to be identified as non-intel. * [Nico] We can focus on FSP-S and publish everything that doesn’t have to be secret as open source. What does intel feel about this? * [Martin]: if we’re doing it as open source, why do it as FSP, why not just do it as coreboot? * David: Look at getting a consortium of companies to sit down with intel and try to work with them to make FSP better. This can’t be done privately, cutting intel out of the loop. * Werner: OSFF is ready to take over things like this instead of doing it as a consortium. Intel has typically even rejected the idea of joining the OSFF to do something like this. * David: Start with contacting intel. I can put Felix in touch with someone from intel. * Sheng: Try building on top of Subrata’s success: 75% of FSPS is getting moved to the platform firmware. * https://blog.osfw.foundation/breaking-the-boundary-a-way-to-create-your-own… * Incorporate Fiano tool as part of Intel coreboot build process to remove the unused FSP modules during build time. That will help to shrink the FSP-S binary by 75%. For the rest of the 25%, the community can start poking around it by trying to implement those as part of native coreboot code. * Resume the work on LibGFXinit. If LibGfx driver is production ready, then we could further shrink FSP-S by removing the graphic init module from it. ### [Arthur] Status update on ARM LBBR bootflow (was asked last meeting) * Nothing to discuss so not sure if this needs to be on the agenda. * Things are progressing along with the LBBR Engineering Change Request to include other bootflow recommendations where coreboot is BL1 * It’s an industry wide spec, so a wide range of partners were asked for input, which takes time * [Martin] We were told in a previous leadership meeting back in October or November that the decision of what to include in the spec would be made at a meeting in January, which is why we pushed so hard to get the decision about the ARM coreboot solutions to be wrapped up. * As far as it being on the agenda, I think even letting us know that things are just progressing but not resolved yet is information that should be shared instead of just leaving people wondering what’s going on. * When should we expect an actual update? June? December? 2025? * [Sheng] No idea..you know how big corporate’s meetings go.. People in the meeting keep asking more questions. As ARM has a wide range of ecosystem partners, and they want to be heard. We are also wondering and equally frustrated, but nothing within 9elements control, we already did our best as possible and keep putting in more resources to help resolve the questions from Arm partners.. Just want to be very cautious here that we did not promise fast approval, but the CB decision was crucial to kickstart the discussion and help to accelerate the process. Hopefully ARM SystemReady will finalize the decision in the coming months. Will share more when we have updates. * When are the patches in question expecting to be merged? * [Sheng] As per I got the confirmation and agreement from leadership in the meeting that with the conditional approval, the patches will be merged immediately after we got confirmation from ARM that the proposed coreboot->TFA is included in the LBBR spec. If the condition changes then will need to bring it up again. ### [Elyes] revert & get rid of write{8,16,32,64}p (readXXp? ). * See Julius’s comment here : https://review.coreboot.org/c/coreboot/+/80193. * Julius: There’s a reason we use void pointers - we want to practice good hygiene and use the correct types for variables. * FelixH: In some cases you have #defines for different MMIO addresses. You need additional typecasts in the code for this. * Werner: Adding the typecast indicates that the developer is doing this intentionally. * David: Something in linux coding guidelines about not hiding pointers as typedefs. This is in the same vein. * Felix & Nico - Agree that removing these will make the code more cluttered. * MaxB: No reason to have these functions - It just hides the typecast. So what if it adds just a bit of clutter. * David: I’d stick with the older format. * Werner: I’m with David - just cast the variable properly. * David: This could also create a bad precedent. * David: Fix the variables that are being passed in rather than casting them? * We’d like one implementation instead of two. Let’s make a decision about what we want to use. * Let’s figure out where the variables are created and see why they’re created with an incorrect type. * FelixH: Get stats of the usage of the different function types. Suspects that most values are actually uintptr_t. ### [Martin] coreboot 24.02 release in just under 2 weeks * Release planned for February 19, 2024. ### [SimonG] Coreboot Control Block again * [Link](https://review.coreboot.org/c/coreboot/+/77712). * Julius doesn’t feel that the benefit is not worth the maintenance cost. * CBFS is the main alternative. CCB should either have its own file or use one of the existing * Wener Zeh, Matt Deviller and David Hendricks generally approve to get this feature in. # Next meeting * February 21, 2024. * [Meeting link](https://bbb.sfconservancy.org/b/mar-sfn-e22-axi). * [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 * [2024-02-07](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1….

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 05 Feb '24

05 Feb '24

Dear community, Please note that the upcoming coreboot leadership meeting is scheduled for Wednesday, February 7, 2024. [1] You are welcome to update the current agenda items with matters you wish to see addressed during the meeting. [2] ## Current Agenda Items ### [Martin/Felix] Switching to BigBlueButton. * The upcoming meeting in two weeks will take place on BigBlueButton instead of Google Chat. Further information will be published to the mailing list between this Wednesday's meeting and the following one. ### [FelixS] Building a community FSP for Intel based platforms * Initial coreboot support for Intel consumer platforms mostly comes with Google Chromebooks. * coreboot support for a wide range of mainboards is only possible if Intel releases FSP binaries. For some platforms Intel refuses to release a FSP binary and Intel also refuses to fix issues within FSP. * How to make coreboot more independent? People have tried convincing Intel to make FSP open source. It seems unlikely that anything in that regard happens any time soon. * As a compromise, I am proposing to build our own FSP from scratch that is built by the community, specifically companies. It's still meant to be closed-source, since Intel won't allow us to write open source code, but then we are able to extend and improve it whenever we want. * Will Intel allow us to distribute our own binaries if the code is completely written by ourselves? * Possible issues * Getting a multi-party NDA * Getting a license so that we are allowed to distribute it * [Werner]The license that comes with the FSP code that I am aware of explicitly inhibits code changes and productive use of self-built binaries. How would we ensure this? * [FelixS] AFAIK the standard license allows us to do code changes but it doesn’t allow us distributing the binary over let’s say a website. So I am wondering if it’s different with something we build ourselves. * [Sheng] Do you have connections with Intel folks to make this happen or initiate the discussion? Is there a solid plan for this, to outline the goals, process, and details with Intel? Or is this just a mere suggestion that is probably not very practical? Since this is not an Intel specific issue, how about AMD? This won't happen overnight - who is going to lead this initiative with Silicon vendors, initiate discussions and meetings (and it will be a difficult and consuming process), collect feedback from all parties, and craft out a solid plan to move ahead? * [Martin] In coreboot’s agreement with SFC, we agreed that any and all software and/or documentation developed and maintained by the Project and the Project’s participants will be distributed solely as Free Software. * Because of this agreement, while this proposed FSP could be interesting to the coreboot group, it’s not, and cannot be, coreboot project. Since we wouldn’t be able to open source the proposed FSP, I’m not even convinced that it’s something that should be discussed in this meeting. ### [Arthur] Status update on ARM LBBR bootflow (was asked last meeting) * Nothing to discuss so not sure if this needs to be on the agenda. * Things are progressing along with the LBBR Engineering Change Request to include other bootflow recommendations where coreboot is BL1 * It’s an industry wide spec, so a wide range of partners were asked for input, which takes time * [Martin] We were told in a previous leadership meeting back in October or November that the decision of what to include in the spec would be made at a meeting in January, which is why we pushed so hard to get the decision about the ARM coreboot solutions to be wrapped up. * As far as it being on the agenda, I think even letting us know that things are just progressing but not resolved yet is information that should be shared instead of just leaving people wondering what’s going on. * When should we expect an actual update? June? December? 2025? * When are the patches in question expecting to be merged? ### [Elyes] revert & get rid of write{8,16,32,64}p (readXXp? ). * See Julius’s comment here: (https://review.coreboot.org/c/coreboot/+/80193) ### [Martin] coreboot 24.02 release in just under 2 weeks * Release planned for Feb 19 [1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

Reworking azalia verb tables
by Nicholas Sudsgaard 03 Feb '24

03 Feb '24

I was told this is a better place for discussion. This is a very experimental change and I would appreciate anyone's opinion on this. :) https://review.coreboot.org/c/coreboot/+/80333

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 02 Feb '24

02 Feb '24

Dear Community, We are pleased to announce that the upcoming coreboot leadership meeting is scheduled for Wednesday, February 7, 2024. [1] Please take a moment to review the current agenda items and update them with matters you wish to see addressed during the meeting. [2] [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2024