coreboot October 2022

coreboot@coreboot.org

16 participants
36 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2022