coreboot

coreboot@coreboot.org

17 participants
39654 discussions

[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

FSP 2.4: runtime blobs!
by Arthur Heymans 30 Sep '22

30 Sep '22

Hi In august FSP2.4 was released with a new feature/component: FSP-I. https://cdrdv2.intel.com/v1/dl/getContent/736809 FSP-I is a blob that initializes SMM and installs a runtime handler and then locks down SMM. Just as a reminder: SMM is a special CPU mode that is entered via a interrupt (SMI) and is completely invisible to the OS. This used to be for power management but now it's often used to avoid writing proper OS drivers e.g. for RAS features. Extract from section 8: "If an FSP binary provides the FSP-I component, usage of FSP-I can be mandatory for certain processors and chipsets. The Integration Guide will document if FSP-I is mandatory for specific FSP implementations." By design coreboot has as little runtime as possible. We also dislike blobs, as it's an open source project. Having closed source code inside a CPU mode that is completely opaque to the OS is going against those 2 wishes at the same time + there already exists open source code for setting SMM. I'd like to start a discussion about not allowing blob runtimes in coreboot before people start writing code to integrate FSP-I. We have had discussions about which blobs are ok and not in the past, with no clear outcome. We don't have a clear policy about what a blob can or cannot do (it only has to be redistributable iirc?), but even without having a clear line of what is ok or not, a runtime blob running on the main CPU is definitely crossing it in my opinion. What are your thoughts? Do we take a stance against FSP-I integration in coreboot? Are there precedents where blobs runtimes are installed on the main CPU, that I don't know of which could justify FSP-I? P.S. It's quite sad to see this happen after an open letter 361 people signed for a more open FSP. https://openletter.earth/adopting-open-source-firmware-approach-for-intel-f… P.S.2 Not all about FSP2.4 is bad. I like that adds the possibility for 64bit support, though it uses the MSVC ABI instead of SYSV :-( . Arthur

4 5

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

27 Sep '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1498391: (TAINTED_SCALAR) /src/commonlib/fsp_relocate.c: 229 in pe_relocate() /src/commonlib/fsp_relocate.c: 256 in pe_relocate() ________________________________________________________________________________________________________ *** CID 1498391: (TAINTED_SCALAR) /src/commonlib/fsp_relocate.c: 229 in pe_relocate() 223 rsize = read_le32(&ophdr->DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC].Size); 224 roffset = read_le32(&ophdr->DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress); 225 printk(FSP_DBG_LVL, "relocation table at offset-%x,size=%x\n", roffset, rsize); 226 // TODO - add support for PE32+ also 227 228 offset = roffset; >>> CID 1498391: (TAINTED_SCALAR) >>> Using tainted variable "roffset + rsize" as a loop boundary. 229 while (offset < (roffset + rsize)) { 230 uint32_t vaddr; 231 uint32_t rlen, rnum; 232 uint16_t *rdata; 233 uint32_t i; 234 EFI_IMAGE_DATA_DIRECTORY *relocd; /src/commonlib/fsp_relocate.c: 256 in pe_relocate() 250 printk(FSP_DBG_LVL, "\t\treloc type %x offset %x aoff %x, base-0x%x\n", 251 rtype, roff, aoff, img_base_off); 252 switch (rtype) { 253 case EFI_IMAGE_REL_BASED_ABSOLUTE: 254 continue; 255 case EFI_IMAGE_REL_BASED_HIGHLOW: >>> CID 1498391: (TAINTED_SCALAR) >>> Using tainted variable "aoff" as an index to pointer "pe_base". 256 val = read_le32(&pe_base[aoff]); 257 printk(FSP_DBG_LVL, "Adjusting %p %x -> %x\n", 258 &pe_base[aoff], val, val + delta); 259 write_le32(&pe_base[aoff], val + delta); 260 break; 261 case EFI_IMAGE_REL_BASED_DIR64: ** CID 1498390: Null pointer dereferences (FORWARD_NULL) /src/commonlib/fsp_relocate.c: 650 in relocate_fvh() ________________________________________________________________________________________________________ *** CID 1498390: Null pointer dereferences (FORWARD_NULL) /src/commonlib/fsp_relocate.c: 650 in relocate_fvh() 644 printk(FSP_DBG_LVL, "TE image at offset %zx\n", 645 section_offset); 646 te_relocate(section_addr, section_data); 647 } else if (read_le8(&csh->Type) == EFI_SECTION_PE32) { 648 printk(FSP_DBG_LVL, "PE32 image at offset %zx\n", 649 section_offset); >>> CID 1498390: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "fih_offset". 650 pe_relocate(new_addr, section_data, fsp, *fih_offset); 651 } 652 653 offset += data_size + data_offset; 654 /* Sections are aligned to 4 bytes. */ 655 offset = ALIGN_UP(offset, 4); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

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