coreboot December 2023

coreboot@coreboot.org

20 participants
50 discussions

[coreboot - Feature #420] (New) Use standard format of TPM event log
by Krystian Hebel 07 Aug '24

07 Aug '24

Issue #420 has been reported by Krystian Hebel. ---------------------------------------- Feature #420: Use standard format of TPM event log https://ticket.coreboot.org/issues/420 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 * Related links: [1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementa… [2] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05… ---------------------------------------- Currently coreboot uses proprietary format for TPM event log. TCG has standardized log formats, differently for TPM1.2 (aka legacy or SHA1) [1] and TPM2.0 (aka crypto agile) [2], both of which can be parsed by Linux kernel and exposed in sysfs. I don't know of any tool outside of cbmem which can parse coreboot format; this includes payloads which may be interested in continuing chain of trust started by coreboot. Another incompatibility is caused by vboot's assignment of PCRs. Roles of PCRs are roughly specified by TCG in both of mentioned documents, they are more or less compatible with each other, but not with current coreboot code. These changes could break assumptions made by existing platforms, so they should be made as Kconfig options. This is a tracking issue to collect subtasks that need to be done in order to support standard event log formats. -- 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

4 12

[coreboot - Feature #433] (New) Unify TPM drivers in coreboot
by Michał Żygowski 24 Apr '24

24 Apr '24

Issue #433 has been reported by Michał Żygowski. ---------------------------------------- Feature #433: Unify TPM drivers in coreboot https://ticket.coreboot.org/issues/433 * Author: Michał Żygowski * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-24 ---------------------------------------- Add an option to compile all drivers for TPM 1.2, 2.0 TIS and CRB. The motivation is to not build multiple coreboot ROMs for each possible TPM supported by the platform. The tasks would include: - runtime TPM detection (probing TPM_INTF_CAPABILITY and TPM_INTERFACE_ID) - rename the TPM driver functions, make them static and expose them as a driver structure, e.g. struct tpm_driver { void (*init)(void); int (*open)(void); int (*close)(void); int (*sendrecv)(const uint8_t *sendbuf, size_t send_size, uint8_t *recvbuf, size_t *recv_len); } - based on the detected TPM, hook the tpm_driver functions to provide the global TPM API: tis_open, tis_close, tis_init, tis_sendrecv. Some additional API to get vendor/device name could also be considered. -- 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

4 6

QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed
by Mike Banon 20 Feb '24

20 Feb '24

If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore: ... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

6 11

[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

Is there a way to enable a PCI-PCI bridge on bus 3 early?
by Keith Hui 11 Jan '24

11 Jan '24

In my quest to get POST codes to show on my Asus P8Z77-M, and fixing sb/bd82x6x [1] along the way, I'm still not quite getting them. I have a ISA/PCI POST card, but it isn't giving me anything. I bought a little "Debug Card Expert" off Amazon that looks like a mini-PCI/mini-PCIe cross, but in today's testing I found out that it isn't wired properly (i.e. isn't going to work) for PCIe at all, but I did get it to show POST codes over LPC via the TPM header. I have another of this same little PoS that broke in half on arrival. Now that I know it only really works over LPC and only 9 signals, I'll attempt to repair the broken traces and glue it together. My board has a PCI-PCI bridge on bus:device.func 3:0.0 (so bus 3, this will be important) that services the PCI slot. After applying [1] to have the PCH send port 80 data to PCI as I specified in Kconfig, I still don't get any POST code... and not over LPC either, so I know my patch works. Now I think I may need to enable CONFIG_EARLY_PCI_BRIDGE. Problem is the bridge has to be a device on bus 0. How can I enable this PCI bridge on bus 3 early so a POST card sitting on it can get codes? Thanks Keith [1] https://review.coreboot.org/c/coreboot/+/79725

2 7

[coreboot - Bug #121] T520: Hangs in OS
by Patrick Rudolph 31 Dec '23

31 Dec '23

Issue #121 has been updated by Patrick Rudolph. It looks like this issue doesn't appear any more when using the MRC.bin instead of native raminit. Thus it's likely that there's a difference between MRC and NRI that causes this issue. ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1725 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 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

1 0

[PATCH] firmware: coreboot: framebuffer: Avoid invalid zero physical address
by Alper Nebi Yasak 27 Dec '23

27 Dec '23

On ARM64 systems coreboot defers framebuffer allocation to its payload, to be done by a libpayload function call. In this case, coreboot tables still include a framebuffer entry with display format details, but the physical address field is set to zero (as in [1], for example). Unfortunately, this field is not automatically updated when the framebuffer is initialized through libpayload, citing that doing so would invalidate checksums over the entire coreboot table [2]. This can be observed on ARM64 Chromebooks with stock firmware. On a Google Kevin (RK3399), trying to use coreboot framebuffer driver as built-in to the kernel results in a benign error. But on Google Hana (MT8173) and Google Cozmo (MT8183) it causes a hang. When the framebuffer physical address field in the coreboot table is zero, we have no idea where coreboot initialized a framebuffer, or even if it did. Instead of trying to set up a framebuffer located at zero, return ENODEV to indicate that there isn't one. [1] https://review.coreboot.org/c/coreboot/+/17109 [2] https://review.coreboot.org/c/coreboot/+/8797 Signed-off-by: Alper Nebi Yasak <alpernebiyasak(a)gmail.com> --- (I was previously told on #coreboot IRC that I could add coreboot mailing list to CC for kernel patches related to coreboot.) drivers/firmware/google/framebuffer-coreboot.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/firmware/google/framebuffer-coreboot.c b/drivers/firmware/google/framebuffer-coreboot.c index c323a818805c..5c84bbebfef8 100644 --- a/drivers/firmware/google/framebuffer-coreboot.c +++ b/drivers/firmware/google/framebuffer-coreboot.c @@ -36,6 +36,9 @@ static int framebuffer_probe(struct coreboot_device *dev) .format = NULL, }; + if (!fb->physical_address) + return -ENODEV; + for (i = 0; i < ARRAY_SIZE(formats); ++i) { if (fb->bits_per_pixel == formats[i].bits_per_pixel && fb->red_mask_pos == formats[i].red.offset && base-commit: 2220f68f4504aa1ccce0fac721ccdb301e9da32f -- 2.42.0

3 2

[coreboot - Bug #521] (New) gizmosphere/gizmo2 development board VGA support not working
by 8oDE 03 24 Dec '23

24 Dec '23

Issue #521 has been reported by 8oDE 03. ---------------------------------------- Bug #521: gizmosphere/gizmo2 development board VGA support not working https://ticket.coreboot.org/issues/521 * Author: 8oDE 03 * Status: New * Priority: High * Category: board support * Target version: none * Start date: 2023-12-24 * Affected versions: 4.18 * Needs backport to: none * Affected hardware: GizmoSphere Gizmo 2 ---------------------------------------- I got a gizmo2 development board. the official hardware and software support stopped a long time ago and no BIOS source code was released. I tried to compile coreboot firmware to support some new features. The latest supported coreboot version is 4.18. I flashed and booted the gizmo2 development board, there is no video output during the coreboot startup phase, but it boots the OS normally and the OS has video output, I purchased a FT232H board for printing logs, and it seems like there are a lot of problems. ``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs_master_header 0x0 cbfs header 32 none config 0x80 raw 562 none revision 0x300 raw 720 none build_info 0x600 raw 103 none spd.bin 0x6c0 spd 128 none fallback/dsdt.aml 0x780 raw 6172 none cmos_layout.bin 0x2000 cmos_layout 616 none fallback/postcar 0x22c0 stage 22312 none payload_config 0x7a40 raw 1621 none payload_revision 0x80c0 raw 237 none (empty) 0x8200 null 31652 none apu/amdfw 0xfdc0 raw 135168 none fallback/romstage 0x30e00 stage 387544 none fallback/ramstage 0x8f880 stage 136240 LZMA (311716 decompressed) pci1002,9830.rom 0xb0d40 optionrom 59392 none fallback/payload 0xbf580 simple elf 72695 none (empty) 0xd11c0 null 3255268 none bootblock 0x3ebdc0 bootblock 16384 none ``` ---Files-------------------------------- coreboot-4.18-bootlog.txt (25.9 KB) .config (15.1 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

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 23 Dec '23

23 Dec '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 5 new defect(s) introduced to coreboot found with Coverity Scan. 442 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 5 of 5 defect(s) ** CID 1532881: (OVERRUN) ________________________________________________________________________________________________________ *** CID 1532881: (OVERRUN) /src/soc/intel/apollolake/mmap_boot.c: 73 in bios_mmap_init() 67 */ 68 bios_mapped_size = size - 256 * KiB; 69 70 rdev_chain_mem(&shadow_dev, (void *)base, bios_mapped_size); 71 72 xlate_window_init(&real_dev_window, &shadow_dev, start, bios_mapped_size); >>> CID 1532881: (OVERRUN) >>> Overrunning struct type xlate_region_device of 24 bytes by passing it to a function which accesses it at byte offset 47. 73 xlate_region_device_ro_init(&real_dev, 1, &real_dev_window, CONFIG_ROM_SIZE); 74 75 bios_size = size; 76 77 /* Check that the CBFS lies within the memory mapped area. It's too 78 easy to forget the SRAM mapping when crafting an FMAP file. */ /src/soc/intel/common/block/fast_spi/mmap_boot.c: 134 in bios_mmap_init() 128 ext_win_flash_base = fixed_win_flash_base - ext_win_size; 129 initialize_window(EXT_BIOS_DECODE_WINDOW, ext_win_host_base, 130 ext_win_flash_base, ext_win_size); 131 win_count++; 132 } 133 >>> CID 1532881: (OVERRUN) >>> Overrunning struct type xlate_region_device of 24 bytes by passing it to a function which accesses it at byte offset 47. 134 xlate_region_device_ro_init(&real_dev, win_count, real_dev_windows, CONFIG_ROM_SIZE); 135 136 init_done = true; 137 } 138 139 const struct region_device *boot_device_ro(void) ** CID 1532880: Integer handling issues (SIGN_EXTENSION) /src/lib/ramtest.c: 58 in test_pattern() ________________________________________________________________________________________________________ *** CID 1532880: Integer handling issues (SIGN_EXTENSION) /src/lib/ramtest.c: 58 in test_pattern() 52 { 53 uint8_t j, k; 54 55 k = (idx >> 8) + 1; 56 j = (idx >> 4) & 0x0f; 57 *addr = idx & 0x0f; >>> CID 1532880: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "j" with type "uint8_t" (8 bits, unsigned) is promoted in "j << 4 * k" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "j << 4 * k" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 58 *addr |= j << (4*k); 59 *value = 0x01010101 << (j & 7); 60 if (j & 8) 61 *value = ~(*value); 62 } 63 ** CID 1532879: Error handling issues (CHECKED_RETURN) /src/soc/intel/apollolake/cpu.c: 255 in post_mp_init() ________________________________________________________________________________________________________ *** CID 1532879: Error handling issues (CHECKED_RETURN) /src/soc/intel/apollolake/cpu.c: 255 in post_mp_init() 249 250 static void post_mp_init(void) 251 { 252 global_smi_enable(); 253 254 if (CONFIG(SOC_INTEL_COMMON_BLOCK_SGX_ENABLE)) >>> CID 1532879: Error handling issues (CHECKED_RETURN) >>> Calling "mp_run_on_all_cpus" without checking return value (as is done elsewhere 4 out of 5 times). 255 mp_run_on_all_cpus(sgx_configure, NULL); 256 } 257 258 static const struct mp_ops mp_ops = { 259 .pre_mp_init = pre_mp_init, 260 .get_cpu_count = get_cpu_count, ** CID 1532878: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1532878: Null pointer dereferences (FORWARD_NULL) /src/soc/qualcomm/common/qup_se_handler.c: 167 in qup_handle_transfer() 161 m_irq = qup_wait_for_m_irq(bus); 162 if ((m_irq & M_RX_FIFO_WATERMARK_EN) || 163 (m_irq & M_RX_FIFO_LAST_EN)) 164 rx_rem_bytes -= handle_rx(bus, din + size 165 - rx_rem_bytes, rx_rem_bytes); 166 if (m_irq & M_TX_FIFO_WATERMARK_EN) >>> CID 1532878: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "dout + size - tx_rem_bytes" to "handle_tx", which dereferences it. 167 tx_rem_bytes -= handle_tx(bus, dout + size 168 - tx_rem_bytes, tx_rem_bytes); 169 if (m_irq & M_CMD_DONE_EN) { 170 write32(&regs->geni_m_irq_clear, m_irq); 171 break; 172 } ** CID 1532877: Resource leaks (RESOURCE_LEAK) /src/soc/intel/common/block/crashlog/crashlog.c: 341 in malloc_cl_node() ________________________________________________________________________________________________________ *** CID 1532877: Resource leaks (RESOURCE_LEAK) /src/soc/intel/common/block/crashlog/crashlog.c: 341 in malloc_cl_node() 335 cl_node_t *node = malloc(sizeof(cl_node_t)); 336 if (!node) 337 return NULL; 338 339 node->data = malloc(len * sizeof(u32)); 340 if (!(node->data)) >>> CID 1532877: Resource leaks (RESOURCE_LEAK) >>> Variable "node" going out of scope leaks the storage it points to. 341 return NULL; 342 343 node->size = len * sizeof(u32); 344 node->next = NULL; 345 346 return node; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Installed memory in DIMM B of both channels. SNB native raminit reports memory in DIMM A?
by Keith Hui 23 Dec '23

23 Dec '23

I'm having more fun with my P8Z77-M. I put my two sticks of GSkill Ripjaws in slots A2 and B2 (aka C0S1, C1S1) following manual recommendations. Surprise 1: It actually worked at full speed now! It previously would totally croak, at least when I hook up serial to watch things go. Installing only one at C1S0 still didn't boot. And that's with me putting my max memory clock back to 800. Surprise 2: This is why I'm writing this email. I got this in the console: ... [DEBUG] memcfg DDR3 ref clock 133 MHz [DEBUG] memcfg DDR3 clock 1596 MHz [DEBUG] memcfg channel assignment: A: 0, B 1, C 2 [DEBUG] memcfg channel[0] config (00630020): [DEBUG] ECC inactive [DEBUG] enhanced interleave mode on [DEBUG] rank interleave on [DEBUG] DIMMA 8192 MB width x8 dual rank [DEBUG] DIMMB 0 MB width x8 single rank, selected [DEBUG] memcfg channel[1] config (00630020): [DEBUG] ECC inactive [DEBUG] enhanced interleave mode on [DEBUG] rank interleave on [DEBUG] DIMMA 8192 MB width x8 dual rank [DEBUG] DIMMB 0 MB width x8 single rank, selected ... Am I seeing things? Why did it report memory in DIMMA when I put my memory in slot 1 only? Regards Keith

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 December 2023