coreboot

coreboot@coreboot.org

6 participants
39686 discussions

[coreboot - Feature #424] (New) Create and implement option to choose either TCG or vboot PCR assignment
by Krystian Hebel 14 Oct '22

14 Oct '22

Issue #424 has been reported by Krystian Hebel. ---------------------------------------- Feature #424: Create and implement option to choose either TCG or vboot PCR assignment https://ticket.coreboot.org/issues/424 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 ---------------------------------------- As with TPM event log, standardized TCG assignment should be chosen by default, with opt-in possibility to choose existing behaviour for platforms that depend on it. -- 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 - Feature #423] (New) Implement legacy and crypto agile TPM event log formats
by Krystian Hebel 14 Oct '22

14 Oct '22

Issue #423 has been reported by Krystian Hebel. ---------------------------------------- Feature #423: Implement legacy and crypto agile TPM event log formats https://ticket.coreboot.org/issues/423 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 ---------------------------------------- Legacy format is simple, it always uses SHA1 and its entries can be described by a C structure, with one field of variable length at the end. Crypto agile format is slightly more complicated. There can be more than one digest in entry, and their sizes depend on algorithm. There is code for marshaling of required structures in security/tpm/tss/tcg-2.0, but it assumes TPM endianness (BE), while entries in event log are always LE. Headers for both formats have vendorInfo field, which can be used to hold additional data, not described by specification. An example of such may be offset to next entry to be added, which saves code from walking through all entries (possibly with different sizes) for each new entry. -- 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 - Feature #422] (New) Create Kconfig menu for TPM event log format
by Krystian Hebel 14 Oct '22

14 Oct '22

Issue #422 has been reported by Krystian Hebel. ---------------------------------------- Feature #422: Create Kconfig menu for TPM event log format https://ticket.coreboot.org/issues/422 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 ---------------------------------------- New entries should default to one of TCG formats, depending on selected TPM family. Choice of other format shouldn't be restricted. Use of current proprietary format should be explicitly selected by boards that depend on it. Additionally, config menu should allow to choose at compilation time the hashing algorithms that are to be used. This would allow for limiting size of code for cases with restricted available space. -- 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 - Bug #310] (Resolved) Coreboot 4.14 fails on a Lenvovo T440p
by Angel Pons 14 Oct '22

14 Oct '22

Issue #310 has been updated by Angel Pons. Affected OS set to All (coreboot bug) Affected hardware set to ThinkPad T440p Status changed from Response Needed to Resolved ---------------------------------------- Bug #310: Coreboot 4.14 fails on a Lenvovo T440p https://ticket.coreboot.org/issues/310#change-1160 * Author: David Hoelscher * Status: Resolved * Priority: Normal * Assignee: Angel Pons * Start date: 2021-06-02 * Affected hardware: ThinkPad T440p * Affected OS: All (coreboot bug) ---------------------------------------- Hi all, coreboot 4.14 dies on early boot. The T440p ended with led blinking and beep sound. This was my first try - so i think it was maybe a problem with mrc.bin or vga.rom. But if I skip back to version 4.13, everything works fine (4.13 working config is appended). I don't know how to get debug information on this early stage of boot. Does anyone has a hint? A Raspberry Pi as an external flasher is available. Further - is it possible to flash only the 4 MB BIOS chip? This IC is very easy accessible. I am afraid to disassemble the complete backplate to access the other 8MB chip again. Initially I flashed the complete Rom without ME on both chips. ---Files-------------------------------- Coreboot_4.13.config (23.6 KB) descriptor.bin (4 KB) -- 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

Does CHIPSET_LOCKDOWN_COREBOOT still work?
by Shawn C 14 Oct '22

14 Oct '22

Hi guys, We've been using SMM only for security chipset lockdown enablement via coreboot payload (VaultBoot) and have tested it on x11ssh-tf (KabyLake) back in 2019 and it works well: ✓ https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/scri… So it's confirmed that users are able to control where or when to enable BIOS LOCK in KabyLake. But it didn't work when I tested coreboot on a coffeelake machine (x11sch) last year. All lockdown is enabled by default regardless of whether CHIPSET_LOCKDOWN_COREBOOT is set or not. IIRC, it is locked down even if I try to disable it via FSP params: https://github.com/intel/FSP/blob/master/CoffeeLakeFspBinPkg/Fsp.bsf#L737 I've been looking into the leaked material from Insyde lately and found out that the NDA'ed FSP seems able to enable/disable any locks out there: https://twitter.com/citypw/status/1580541897604751361 Is this a bug or a feature that intends not to allow users to disable BIOS lock (others as well) via Intel' public FSP binary blobs? Thanks, regards Shawn [1] FSP-S Issues https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/changes/28/3632…

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 12 Oct '22

12 Oct '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1498959: (STRING_OVERFLOW) /src/mainboard/prodrive/hermes/mainboard.c: 183 in format_pn() /src/mainboard/prodrive/hermes/mainboard.c: 182 in format_pn() ________________________________________________________________________________________________________ *** CID 1498959: (STRING_OVERFLOW) /src/mainboard/prodrive/hermes/mainboard.c: 183 in format_pn() 177 static char buffer[32 + HERMES_SN_PN_LENGTH] = { 0 }; 178 179 const char *part_num = eeprom_read_serial(offset, "N/A"); 180 181 memset(buffer, 0, sizeof(buffer)); 182 strcpy(buffer, prefix); >>> CID 1498959: (STRING_OVERFLOW) >>> You might overrun the 64-character fixed-size string "buffer + strlen(prefix)" by copying "part_num" without checking the length. 183 strcpy(buffer + strlen(prefix), part_num); 184 185 return buffer; 186 } 187 188 static void mainboard_smbios_strings(struct device *dev, struct smbios_type11 *t) /src/mainboard/prodrive/hermes/mainboard.c: 182 in format_pn() 176 { 177 static char buffer[32 + HERMES_SN_PN_LENGTH] = { 0 }; 178 179 const char *part_num = eeprom_read_serial(offset, "N/A"); 180 181 memset(buffer, 0, sizeof(buffer)); >>> CID 1498959: (STRING_OVERFLOW) >>> You might overrun the 64-character fixed-size string "buffer" by copying "prefix" without checking the length. 182 strcpy(buffer, prefix); 183 strcpy(buffer + strlen(prefix), part_num); 184 185 return buffer; 186 } 187 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

3 4

RFC: Intention to join Open Source Firmware Foundation
by David Hendricks 09 Oct '22

09 Oct '22

Hi everyone, As mentioned in this week's leadership meeting, membership in the Open Source Firmware Foundation (OSFF) has been under consideration for some time and we feel that we should move ahead. We plan to join by the end of this month if possible. This will be in addition to our membership with the Software Freedom Conservancy who handles donations to coreboot.org and legal services and will continue to do so. We've reviewed membership documents and so far we do not see any conflict in this arrangement. From a community standpoint, we'd like to know if there are any objections or good reasons *not* to move ahead with membership in OSFF. Feel free to reply on the list or in private with your thoughts. More info about OSFF can be found here: https://opensourcefirmware.foundation/

2 2

Stuck on SB clock to SIO.
by Pedro Erencia 08 Oct '22

08 Oct '22

Hi everyone. I'm a bit stuck on this. As I've said before in other emails here, I'm trying to bring up an AsRock FM2A88X+ with coreboot. I've used as a model the code for the a88xm-e and accomplished my first goal, which was to have a working UART, but I need to boot with the original AMI BIOS first (first boot after mechanical off) for it to work. The problem seems to be the 48 MHz clock that SB feeds to the SIO. Coreboot's a88xm-e code has the code to configure it early, in sbxxx_enable_48mhzout, and so have I, but I've checked it with an oscilloscope and there's no clock there, So I turned to the docs. Regarding that clock, we can read, "The USBCK/14M_25M_48M_OSC pin (G8) as well as the 14M_25M_48M_OSC pin (J26) output a 14.318MHz clock on the first power up if the internal system clock generator mode strap is selected. [1] 14M_25M_48M_OSC is the pin we are interested in. From what I see on the boardfile, the strap is configured as internal system clock. Later, "The output will generate 12.5 MHz on power up after the FCH PWR_GOOD is asserted. The output frequency will be 12.5 MHz until the internal PLL is initialized after which time the output will switch to 14.318 MHz clock." [2] So, it seems that, after the FCH PWR_GOOD and *without any firmware intervention*, we should get 12.5 MHz on that pin. I've checked it with the original AMI BIOS and that's correct, ~150 ms after the assertion of PWR_GOOD we get the 12.5 MHz clock. On the other hand, with my coreboot image, FCH PWR_GOOD is asserted, but there is no clock. From what I said, I deduce that the AMI BIOS must be doing something that I do not, but, as I understand the databook, the 12.5 MHz should be *automatic* after a PWR_GOOD. Maybe someone with more experience with AMD chipsets could help me here, especially considering that we have a working image with the same chipset. I'd appreciate any hints or advice about how to proceed. [1] Bolton Databook ( https://www.amd.com/system/files/TechDocs/Bolton_D2-D2H-D3-D4_Databook.pdf), Chapter 4, Table 13 [2] Bolton Databook, Chapter 6, Table 52

2 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 07 Oct '22

07 Oct '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 new defect(s) introduced to coreboot found with Coverity Scan. 35 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1498916: (STRING_OVERFLOW) ________________________________________________________________________________________________________ *** CID 1498916: (STRING_OVERFLOW) /src/arch/x86/smbios.c: 1068 in smbios_write_type28() 1062 u32 oem, 1063 u16 nominal_value) 1064 { 1065 struct smbios_type28 *t = smbios_carve_table(*current, SMBIOS_TEMPERATURE_PROBE, 1066 sizeof(*t), *handle); 1067 >>> CID 1498916: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "name" without checking the length. 1068 t->description = smbios_add_string(t->eos, name ? name : "Temperature"); 1069 t->location_and_status = location | (status << 5); 1070 t->maximum_value = max_value; 1071 t->minimum_value = min_value; 1072 t->resolution = resolution; 1073 t->tolerance = tolerance; /src/arch/x86/smbios.c: 1068 in smbios_write_type28() 1062 u32 oem, 1063 u16 nominal_value) 1064 { 1065 struct smbios_type28 *t = smbios_carve_table(*current, SMBIOS_TEMPERATURE_PROBE, 1066 sizeof(*t), *handle); 1067 >>> CID 1498916: (STRING_OVERFLOW) >>> You might overrun the 2-character destination string "t->eos" by writing 12 characters from ""Temperature"". 1068 t->description = smbios_add_string(t->eos, name ? name : "Temperature"); 1069 t->location_and_status = location | (status << 5); 1070 t->maximum_value = max_value; 1071 t->minimum_value = min_value; 1072 t->resolution = resolution; 1073 t->tolerance = tolerance; ** CID 1498915: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 602 in write_from_buf_to_file() ________________________________________________________________________________________________________ *** CID 1498915: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 602 in write_from_buf_to_file() 596 bytes = write(fd, buf + total_bytes, buf_size - total_bytes); 597 if (bytes < 0 && errno == EAGAIN) 598 bytes = 0; 599 600 if (bytes < 0) { 601 fprintf(stderr, "Write failure %s\n", strerror(errno)); >>> CID 1498915: Error handling issues (CHECKED_RETURN) >>> Calling "lseek(fd, 1L, -total_bytes)" without checking return value. This library function may fail and return an error code. 602 lseek(fd, SEEK_CUR, -total_bytes); 603 return bytes; 604 } 605 606 total_bytes += bytes; 607 } while (total_bytes < buf_size); ** CID 1498914: Security best practices violations (STRING_OVERFLOW) ________________________________________________________________________________________________________ *** CID 1498914: Security best practices violations (STRING_OVERFLOW) /src/arch/x86/smbios.c: 1155 in smbios_write_type43() 1149 t->major_spec_ver = major_spec_ver; 1150 t->minor_spec_ver = minor_spec_ver; 1151 t->fw_ver1 = fw_ver1; 1152 t->fw_ver2 = fw_ver2; 1153 t->characteristics = characteristics; 1154 t->oem_defined = oem_defined; >>> CID 1498914: Security best practices violations (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "description" without checking the length. 1155 t->description = smbios_add_string(t->eos, description); 1156 1157 const int len = smbios_full_table_len(&t->header, t->eos); 1158 *current += len; 1159 *handle += 1; 1160 return len; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

[coreboot - Feature #417] (New) Show platform key on boot when secure boot is enabled
by Simon Brand 02 Oct '22

02 Oct '22

Issue #417 has been reported by Simon Brand. ---------------------------------------- Feature #417: Show platform key on boot when secure boot is enabled https://ticket.coreboot.org/issues/417 * Author: Simon Brand * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-02 * Related links: [0] https://source.android.com/docs/security/features/verifiedboot/boot-flow#lo… [1] https://issuetracker.google.com/issues/217720443 [2] https://source.codeaurora.org/quic/la/abl/tianocore/edk2/tree/QcomModulePkg… * Affected hardware: All * Affected OS: All but Windows ---------------------------------------- I think it is useful to show the hash of the platform key, if a different platform key than default (Microsoft trusted Platform Key) is the current platform key and secure boot is enabled. It must be shown, before the operating system could have been started (to avoid the OS showing it with an older UEFI, which lacks this feature), also it makes sense to pause the screen, so you can verify the hash. Why? To make sure the correct operation system is loading and nobody tampered the devices platform key and disk. Android smartphones have this feature for several years. [0] Please keep in mind, that the screenshots are not fully up-to-date, devices show not only the first 8 digits, but the full root of trust hash since a few months. [1] The reference source code is available here: [2] -- 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot