May 2026 - coreboot - mail.coreboot.org

[coreboot - Bug #576] (New) GPIO locking is broken on Kaby Lake and possibly other platforms
by Mate Kukri June 3, 2026

June 3, 2026

Issue #576 has been reported by Mate Kukri. ---------------------------------------- Bug #576: GPIO locking is broken on Kaby Lake and possibly other platforms https://ticket.coreboot.org/issues/576 * Author: Mate Kukri * Status: New * Priority: Normal * Target version: none * Start date: 2025-01-30 ---------------------------------------- Many supported Kaby Lake boards (and possibly newer platforms as well) are vulnerable to [TPM GPIO reset attacks](https://mkukri.xyz/2024/06/01/tpm-gpio-fail.html). Trying to fix this by marking the affected GPIOs as locked in gpio.h and even also selecting `SOC_INTEL_COMMON_BLOCK_SMM_LOCK_GPIO_PADS` does not work. This was discovered last year and briefly discussed on #coreboot, but it came up again on the Heads matrix group in relation to supporting the TPM on the in-progress ThinkPad T480 port. -- 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

3 5

The Plan 9 foundation is looking for old hardware
by ron minnich May 28, 2026

May 28, 2026

if anyone has old hardware they no longer need, x86 or ARM, the Plan 9 foundation is trying to stand up a rack in a colo in paris. If you have contacts, please let me know. thanks

1 0

2026-05-27 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org May 28, 2026

May 28, 2026

# 2026-05-27 - coreboot Leadership Meeting ## Open Action Items * 2024-10-30 * [Open] Add clarification to docs: “Do not use gerrit change-id or CB: format in reference to already-merged patches.” * 2024-10-16 * [Open] Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * [Open] Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * [Open] Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?). * 2024-01-10 * 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. ## Announcements & Events * Next Open System Firmware - OCP Project Meeting * Date : [June 4, 2026](https://coreboot.org/calendar.html) * [OSFC 2026](https://www.osfc.io) * Date: 15 - 17 September * CFP open until 2026/06/22 ## Attendees Mina Asante, Werner Zeh, Jay Talbott, Alicja Michalska, Julius Werner, David Hendricks. ## Minutes ### [Julius] – Google is ready to supply the yearly $15K infrastructure support, we need an invoice to know who to send it to. * [Werner] We need to ask SFC for the invoice, Pono might be a good contact to go for. I will reach out to him via e-mail and ask. ### [Werner] What do fold think of Intel’s Trace Hub (aka NorthPeak)? Shall we go for it in coreboot or do we have objections? * [Alicja] Sounds like a good option for overall system debugging * [David] Would be a good possibility to have joint logs from various system parts (not only x86 host). * [Jay Talbott] No objections so far. * [Werner] Will take a closer look if it can be implemented for coreboot. # Next Leadership Meeting Date * June 10, 2026. * [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 Notes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK….

1 0

Re: ENC: Board support request for Lenovo IdeaPad 330 (Kaby Lake-R) - Stock Dump from Brazil
by Alicja Michalska May 27, 2026

May 27, 2026

> I would like to donate the firmware dump of my laptop to help add official board support for the Lenovo IdeaPad 330 (Intel Kaby Lake-R / MX150) in the main coreboot tree. Firmware dump doesn't help with anything unless it has EC firmware included (and usually EC has it's own SPI flash). > Location: This laptop was manufactured and purchased in Brazil (it features the localized motherboard and keyboard layout). > Privacy/Keys: This is a completely stock, unmodified 8MB dump. It still contains my private NVRAM data, including my Windows OEM activation key and system serial numbers, because I wasn't able to clear it on my end. Again, doesn't matter. Vendors release only one firmware worldwide, otherwise it would be a nightmare to maintain. > Please sanitize or clear the NVRAM region before parsing the file or using it for any upstream commits. You already leaked your Windows key by publishing your MSDM table on the issue tracker. Anyone can download it, run xxd and obtain your Windows key. You NEVER use stock NVRAM or ACPI tables for anything other than reference (especially EC). > This dump should have all the necessary information to map the devicetree, GPIOs, and PCIe routing for this specific Brazilian model. It will not. With all due respect, nobody will spend their time reverse-engineering UEFI image, we have toolkit for obtaining this information from a running system. We cannot re-distribute IFD or ME binaries for licensing reasons (especially since ME region dumped from running system is "dirty"). If you *truly* want to contribute, please watch this talk first. I didn't go over EC-specific stuff (especially since this would be ~30 minutes on it's own), but should give you at least *some* idea how to approach this: https://media.ccc.de/v/38c3-corebooting-intel-based-systems You should know what to do after listening to it and looking at example commits on gerrit. System should boot even without EC code (assuming it won't be killed by a watchdog), but of course built-in keyboard (ATKBD), fan control and suspend wouldn't work without it. Asking for help when you get stuck/need an RFC about implementation approach is fine. Begging community to spend their time to port coreboot to a random old laptop and calling it a "contribution" is not. On 24/05/2026 14:00, Heitor Ramos Assunção wrote: > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *De:* Heitor Ramos Assunção > *Enviado:* sábado, 23 de maio de 2026 13:18 > *Para:* coreboot(a)coreboot.org <coreboot(a)coreboot.org> > *Assunto:* Board support request for Lenovo IdeaPad 330 (Kaby Lake-R) - Stock Dump from Brazil > > Hi, > > I would like to donate the firmware dump of my laptop to help add official board support for the Lenovo IdeaPad 330 (Intel Kaby Lake-R / MX150) in the main coreboot tree. > > Important notes about this file: > * Location: This laptop was manufactured and purchased in Brazil (it features the localized motherboard and keyboard layout). > * Privacy/Keys: This is a completely stock, unmodified 8MB dump. It still contains my private NVRAM data, including my Windows OEM activation key and system serial numbers, because I wasn't able to clear it on my end. > > Please sanitize or clear the NVRAM region before parsing the file or using it for any upstream commits. > > This dump should have all the necessary information to map the devicetree, GPIOs, and PCIe routing for this specific Brazilian model. > > Thank you for your help in upstreaming support for this device! > > Best regards, > Osty > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org

1 0

Re: ENC: Board support request for Lenovo IdeaPad 330 (Kaby Lake-R) - Stock Dump from Brazil
by Matt DeVillier May 27, 2026

May 27, 2026

hi Osty, As others have already explained on the bug tracker, a firmware dump from the board provides little useful information for porting; things like GPIOs cannot be easily extracted from it. And no one will port this board for fun unless they own one themselves and are motivated to do so. If you want to learn to port it yourself, the various discussion channels (IRC, Slack, Discord, Matrix) are a better way to get real-time help than the mailing list cheers, Matt On Wed, May 27, 2026 at 4:36 AM Heitor Ramos Assunção <heitor_assuncao2017(a)outlook.com> wrote: > > > ________________________________ > De: Heitor Ramos Assunção > Enviado: sábado, 23 de maio de 2026 13:18 > Para: coreboot(a)coreboot.org <coreboot(a)coreboot.org> > Assunto: Board support request for Lenovo IdeaPad 330 (Kaby Lake-R) - Stock Dump from Brazil > > Hi, > > I would like to donate the firmware dump of my laptop to help add official board support for the Lenovo IdeaPad 330 (Intel Kaby Lake-R / MX150) in the main coreboot tree. > > Important notes about this file: > * Location: This laptop was manufactured and purchased in Brazil (it features the localized motherboard and keyboard layout). > * Privacy/Keys: This is a completely stock, unmodified 8MB dump. It still contains my private NVRAM data, including my Windows OEM activation key and system serial numbers, because I wasn't able to clear it on my end. > > Please sanitize or clear the NVRAM region before parsing the file or using it for any upstream commits. > > This dump should have all the necessary information to map the devicetree, GPIOs, and PCIe routing for this specific Brazilian model. > > Thank you for your help in upstreaming support for this device! > > Best regards, > Osty > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org

1 0

[coreboot - Feature #649] (New) yes again support for ideapad but im not needing help i just want contribuition and contribuition means help
by heitor ramos assunção May 26, 2026

May 26, 2026

Issue #649 has been reported by heitor ramos assunção. ---------------------------------------- Feature #649: yes again support for ideapad but im not needing help i just want contribuition and contribuition means help https://ticket.coreboot.org/issues/649 * Author: heitor ramos assunção * Status: New * Priority: Normal * Target version: none * Start date: 2026-05-26 * Due date: 2026-06-30 * Affected versions: main * Needs backport to: main * Affected hardware: my ideapad * Affected OS: all ---------------------------------------- yes again support for ideapad but im not needing help i just want contribuition and contribuition means help and this is git diff ---Files-------------------------------- git-diff.txt (826 Bytes) -- 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

2 2

[coreboot - Support #644] (New) support for ideapad 330 15ikbr
by heitor ramos assunção May 25, 2026

May 25, 2026

Issue #644 has been reported by heitor ramos assunção. ---------------------------------------- Support #644: support for ideapad 330 15ikbr https://ticket.coreboot.org/issues/644 * Author: heitor ramos assunção * Status: New * Priority: Normal * Target version: main * Start date: 2026-05-24 * Affected versions: main * Needs backport to: main * Affected hardware: intel kaby lake/coffe lake * Affected OS: all ---------------------------------------- this is a requeset for ideapad support ---Files-------------------------------- lenovo_330_coreboot_all.tar.zst (5.32 MB) -- 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

2 24

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org May 25, 2026

May 25, 2026

Dear coreboot Community, Please be reminded that our upcoming coreboot leadership meeting is scheduled for Wednesday, May 27, 2026. [1] Kindly update the agenda with any issues you'd like to discuss during the meeting. [2] Thank you. Best regards, Mina. ## Current Agenda Items * No active issues on the agenda yet. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

[coreboot - Bug #647] (New) ec/lenovo/h8: ThinkLight is always-on with specific `backlight` CMOS options on ThinkPad X230
by Christian Schrötter May 25, 2026

May 25, 2026

Issue #647 has been reported by Christian Schrötter. ---------------------------------------- Bug #647: ec/lenovo/h8: ThinkLight is always-on with specific `backlight` CMOS options on ThinkPad X230 https://ticket.coreboot.org/issues/647 * Author: Christian Schrötter * Status: New * Priority: Low * Target version: none * Start date: 2026-05-25 * Affected versions: main * Affected hardware: Lenovo ThinkPad X230 ---------------------------------------- The ThinkPad X230 supports the following values for the option *"Keyboard Illumination Device"* (Config » Keyboard/Mouse) in the stock BIOS. These states are represented in EC RAM register `0x01` via bits 2-3: * **Both**: `0x00` * **Keyboard Backlight Only**: `0x04` (bit 2 set) * **ThinkLight Only** : `0x08` (bit 3 set) coreboot implements this setting via the `backlight` CMOS option. Additionally, there's a 4th (undocumented?) value in coreboot, which is apparently supported by some ThinkPads: * **None** : `0x0c` (bit 2 and 3 set) I've successfully tested `backlight=Keyboard` and `backlight=None` on a T440p with coreboot, without any issues. ## Bug description However, X230's behaviour under coreboot is broken for specific settings: * `backlight=Both` and `backlight=Thinklight only`: Works as expected. * `backlight=None` or `backlight=Keyboard only`: ThinkLight is always-on! In this "always-on" state, there's no way to turn off ThinkLight. Even pressing Fn+Space is completely ignored by the EC. ## Debugging Attempts & Observations * I suspected a race condition during EC initialization and tried to forcefully disable the ThinkLight during `h8_enable()` before `config1` gets written. - Result: This didn't work. The ThinkLight remains always-on. ([see my attempt on GitHub](https://github.com/froonix/coreboot/commit/c87e9469eb7deb885e4affce…) * It appears that setting bit 2 in `0x01` doesn't just disable the feature, but rather locks out the EC entirely from controlling the physical GPIO pin, leaving it floating/high. * The catch (timing): There is one exception! The ThinkLight correctly switches off during the very first cold boot right after flashing the BIOS region; when the MRC cache is invalid. The lengthy RAM training delay somehow prevents the issue. This strongly points towards a timing or race condition issue during the EC's own initialization phase versus coreboot sending the commands. Currently, I'm out of ideas on how to properly debug or fix this EC quirk. Any hints from a coreboot veteran would be highly appreciated. :-) -- 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

1 0

[coreboot - Bug #645] (New) PCR 0 extended without a corresponding TCG event-log entry on Meteor Lake / FSP coreboot builds
by Cédric Bussy May 24, 2026

May 24, 2026

Issue #645 has been reported by Cédric Bussy. ---------------------------------------- Bug #645: PCR 0 extended without a corresponding TCG event-log entry on Meteor Lake / FSP coreboot builds https://ticket.coreboot.org/issues/645 * Author: Cédric Bussy * Status: New * Priority: High * Category: coreboot common code * Target version: main * Start date: 2026-05-24 * Affected hardware: Star Labs StarFighter, Intel Core Ultra 5 125H (Meteor Lake) * Affected OS: openSUSE Tumbleweed, kernel 7.0.x, systemd-boot 260.1 ---------------------------------------- **1. Summary** On a Star Labs StarFighter (Intel Core Ultra 5 125H, Meteor Lake) running Star Labs firmware 26.05 (coreboot 26.03-549-g120be1d4d488), PCR 0 holds a non-zero value at runtime, but the TCG event log exposed by the firmware contains no EV_* measurement targeting PCR 0 — only the EV_NO_ACTION Spec ID header (which, per the TCG spec, does not extend the PCR). All real measurements are recorded against PCR 2. Consequently, systemd-pcrlock (used by openSUSE sdbootutil) reconstructs an expected PCR 0 from the log, obtains the initial/reset value, compares it to the actual register, and fails: Event log for PCR 0 does not match PCR state, refusing. This blocks TPM2 measured-boot operations (boot-entry regeneration, pcrlock prediction) on every kernel/bootloader update and whenever a tool re-invokes sdbootutil. Note: direct systemd-cryptenroll sealing (which snapshots current PCR values rather than predicting them) is unaffected and works — so this is specifically a pcrlock/event-log-reconstruction issue, not a cryptenroll one. **2. Evidence** PCR state (tpm2_pcrread sha256:0,4,7,9) 0 : 0x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969 4 : 0xAED40B050E1BA97F3AE98794456DDD937ACD41EC0D7602580A088683DD32457C 7 : 0x2C71FF90E89217C2B534F24FE456BC6FDE79E90517634D6CED60B4D7AE0A2267 9 : 0xEEC49DD0A2BD6FCAECF0FD28D3E15382E94A34956D37DB7501FC081359D8B645 PCR 0 is non-zero — it has been extended during this boot. Event log (tpm2_eventlog .../binary_bios_measurements) • The only entry with PCRIndex: 0 is EventNum 0, EventType: EV_NO_ACTION (Spec ID Event03; vendorInfo identifies coreboot — CBT22). EV_NO_ACTION does not extend the PCR. • Every measurement event (EventNum 1–12, EV_ACTION) targets PCR 2: CBFS: bootblock, fallback/romstage, fspm.bin, spd.bin, fallback/postcar, fallback/ramstage, cpu_microcode_blob.bin, fsps.bin, vbt_qhd.bin, fallback/dsdt.aml, fallback/payload. • The log-reconstructed pcrs: section lists only sha256: 2 : 0x5bd7…. PCR 0 is absent because the log carries no extending measurement for it. The inconsistency • Reconstructed-from-log PCR 0 = initial value (no extending events). • Actual PCR 0 = 0x3D458CFE…. • → deterministic mismatch. **3. Open question for maintainers (likely root cause)** coreboot measures its own components into PCR 2 and documents PCR 0 as Unused on non-CHROMEOS builds — consistent with the log above. Yet PCR 0 is extended. On Meteor Lake the silicon init runs through Intel FSP (fspm.bin / fsps.bin, both visible in the PCR 2 measurements). The most plausible explanation is that the FSP (or a pre-coreboot CRTM) extends PCR 0 without the measurement being reflected in coreboot's TCG event log. Questions: 1. Is PCR 0 expected to be extended on Meteor Lake FSP-based builds despite the "Unused" documentation? 2. If the extension comes from FSP, can coreboot surface those measurements into the TCG event log so that PCR 0 becomes reconstructible — or should PCR 0 be left genuinely unextended on these builds? This is not asserted as a coreboot-only fix; it may require FSP-side coordination. The report's purpose is to surface a reproducible event-log / PCR-0 inconsistency and determine the correct remediation path. **4. Affected scope** • Confirmed: Star Labs StarFighter (Core Ultra 5 125H, Meteor Lake), coreboot firmware 26.05, openSUSE Tumbleweed, Secure Boot enabled (user mode). • Potentially: any coreboot/FSP build where PCR 0 is extended outside the TCG event log, combined with an OS that defaults to sdbootutil / systemd-pcrlock / measured UKI for TPM2 LUKS. **5. Reproduction** 1. coreboot/FSP build, non-CHROMEOS, TPM2 active, Secure Boot user mode. 2. Install openSUSE Tumbleweed (defaults to sdbootutil / systemd-pcrlock for measured UKI + TPM2 LUKS). 3. TPM2 enrolment / boot-entry regeneration fails with the §1 error. Correlated install-time symptoms: Event log for PCR 0 does not match PCR state, refusing. find: '/var/lib/pcrlock.d/': No such file or directory warning: %posttrans(coreutils-<ver>.x86_64) scriptlet failed, exit status 1 The pcrlock.d and %posttrans errors are downstream of the gated PCR 0 validation, not independent faults. **6. Current mitigation (reporter's system)** measure-pcr-validator.ignore=yes # /etc/kernel/cmdline LUKS sealing then performed via systemd-cryptenroll against PCR 7+9 (PCR 4 dropped to avoid re-enrolment on every bootloader change). Automatic unlock works; the firmware-measurement (PCR 0) link is excluded from the policy. Stated as a mitigation, not a fix. **7. Environment** • Device: Star Labs StarFighter; Intel Core Ultra 5 125H (Meteor Lake, stepping C0, microcode 0x28) • Firmware: Star Labs 26.05, built on coreboot 26.03-549-g120be1d4d488 (build 2026-04-30 UTC) • Intel ME: disabled • OS: openSUSE Tumbleweed, kernel 7.0.x, systemd-boot 260.1 • Secure Boot: enabled (user mode, custom keys enrolled) • TPM: 2.0, sha256 bank • systemd 260.1-2.1 • sdbootutil 1+git20260506.25d47bf-1.1 • tpm2.0-tools 5.7-2.5 -- 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

2 2