coreboot

coreboot@coreboot.org

36 participants
38420 discussions

[RFC] Change in CBFS "stage" binary format

by Julius Werner

Hi folks, As some of you may know, I've been working on a way to add verification directly into CBFS (as opposed to the current vboot that can only verify images as a whole) for a while (I have presented at OSFC 2019: https://www.youtube.com/watch?v=Hs_EhewBgtM and published a general design document: https://osfc.io/uploads/talk/paper/47/The_future_of_firmware_verification_i…). As part of this work I have been very careful to keep all these changes fully backwards-compatible so that existing payloads with their own CBFS implementations will continue to work. I have now come across a fundamental problem that I cannot solve without introducing a small backwards-incompatible change: the CBFS "stage" format that is used to store the code for coreboot stages (e.g. romstage, ramstage) consists of a small "stage header" containing things like load address and size in front of the actual binary code. From the point of view of the generic CBFS structure, both that header and the code are part of the "file data" (and not the generic CBFS "file header" that contains things like the file name or generic CBFS attributes). This creates a tough chicken-and-egg problem when verifying pre-RAM stages, because (for platforms that actually load pre-RAM stages and don't execute in-place, like Arm platforms running from SRAM) the stage needs to be directly loaded into the final location it should execute out of, but the load address containing that location is in the stage header. My verification design works on whole files, so the stage header cannot be trusted before the whole file was loaded and hashed. But I can't load it without information from the stage header, and there's generally not enough scratch space in these pre-RAM environments to first load it somewhere else and then copy it over to its final destination after verification. My solution to this problem is to move the stage header out of the file data into a CBFS attribute that is stored in the generic CBFS file header. File headers are verified separately so they can already be trusted by the time the file data needs to be loaded. I think this is arguably a somewhat cleaner approach anyway (the concept of CBFS attributes just didn't exist yet when the stage format was originally designed, so it wasn't written that way to start with), but of course these new stages will be incompatible to the old ones. I believe this is okay because the "stage" format is generally only used for parts of coreboot itself (e.g. romstage, ramstage), whereas the payload and other binaries the payload may want to chain-load should be using the "simple ELF" (SELF) format anyway. Since coreboot is always built as a whole, when you're gonna build the new version all your stages will be in the new format and all code that loads them will know how to load the new format, so you should be fine. Tying this into a payload build system that is not aware of these changes should be okay because that payload shouldn't try to add extra files using the "stage" format, and shouldn't try to load any stages (if it wants to chain-load things it should be using the SELF format with cbfstool add-payload, not add-stage). But this file format has remained untouched for the whole 10+ years CBFS existed, so I thought I should ask before I do it. If you know any payloads that do use the "stage" format for files outside of coreboot itself and that couldn't adapt to this change for some reason, or have any other concerns about unexpected problems this could be causing you, please let me know here or on the CL: https://review.coreboot.org/46484 Note that for cbfstool, this will also mean that newer versions of cbfstool will only support the new format. I think this should also be okay because coreboot is built as a whole, i.e. all your stages are added with a cbfstool version that was built from the same code base version as the coreboot code trying to load these stages. But it does mean that if you have an old version of cbfstool stashed away somewhere and try to use it to cbfstool print -v or cbfstool extract a new coreboot image, it won't be able to show load address or entry point for the new stages or convert them back into an ELF file on extraction (or vice versa for new versions of cbfstool on old images). So if you do a lot of after-the-fact cbfstool manipulation on different versions of coreboot images (which is probably only done by people trying to debug something?), you may need to keep two cbfstool versions to switch back-and-forth between for a while. It would be possible to make the new cbfstool version support both formats for reading/extracting but that's a bunch of extra work that I hope I can avoid unless people really feel like this is gonna be a widespread problem. Also note that I'm not planning to touch the SELF (payload) format (which also has a header in the "file data" part) -- I will keep that as it is because I think it's much more likely that external payloads are using it for their own purposes that I don't want to break. It's also not necessary because SELFs are mostly just used in post-RAM environments and the SELF loader code already requires it (on non-memory-mapped platforms) to be loaded to a separate scratch buffer before copying the individual pieces to where they need to go. When we have that buffer anyway, it's easy to verify the whole file in there before examining the header.

2 hours, 31 minutes

[RFC] Replace strapping entries in coreboot table

by Tim Wawrzynczak

Hi coreboot community, Currently there are 3 different "strapping" entries in the coreboot tables, and with the recent addition of fw_config ( https://review.coreboot.org/c/coreboot/+/41209), we would also like to add the 64-bit fw_config field (updated here https://review.coreboot.org/c/coreboot/+/45939) to the coreboot table as well. In this patch (https://review.coreboot.org/c/coreboot/+/46605), I am proposing to deprecate the 3 current "strapping" entries (board ID, ram code and SKU ID), and add them all to 1 entry, containing board ID, ram code, SKU ID as well as fw_config. This saves the overhead of parsing 4 different entries to obtain board configuration information. Would like to hear any thoughts on this, - Tim

2 hours, 42 minutes

New Defects reported by Coverity Scan for coreboot

by scan-admin＠coverity.com

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. 2 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 2 of 2 defect(s) ** CID 1435893: Integer handling issues (BAD_SHIFT) /tests/lib/imd-test.c: 30 in align_up_pow2() ________________________________________________________________________________________________________ *** CID 1435893: Integer handling issues (BAD_SHIFT) /tests/lib/imd-test.c: 30 in align_up_pow2() 24 #define SM_ENTRY_ID 0xB001 25 26 #define INVALID_REGION_ID 0xC001 27 28 static uint32_t align_up_pow2(uint32_t x) 29 { >>> CID 1435893: Integer handling issues (BAD_SHIFT) >>> In expression "1 << log2_ceil(x)", shifting by a negative amount has undefined behavior. The shift amount, "log2_ceil(x)", is -1. 30 return (1 << log2_ceil(x)); 31 } 32 33 static size_t max_entries(size_t root_size) 34 { 35 return (root_size - sizeof(struct imd_root_pointer) - sizeof(struct imd_root)) ** CID 1435892: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1435892: Null pointer dereferences (FORWARD_NULL) /tests/lib/imd-test.c: 605 in test_imd_entry_at() 599 fail_msg("Cannot allocate enough memory - fail test"); 600 imd_handle_init(&imd, (void *)(LIMIT_ALIGN + (uintptr_t)base)); 601 602 assert_int_equal(0, imd_create_empty(&imd, LG_ROOT_SIZE, LG_ENTRY_ALIGN)); 603 604 /* Fail when entry is NULL */ >>> CID 1435892: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "e" to "imd_entry_at", which dereferences it. 605 assert_null(imd_entry_at(&imd, e)); 606 607 entry = imd_entry_add(&imd, LG_ENTRY_ID, LG_ENTRY_SIZE); 608 assert_non_null(entry); 609 610 r = (struct imd_root *)imd.lg.r; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 day, 10 hours

Coreboot Picasso FSP questions

by chen.kenyy＠inventec.com

Hi, I study in AMD AGESA v9 boot in the coreboot. So far, I boot to the FSP image failed as below log. CBFS: Locating 'fspm.bin' CBFS: 'fspm.bin' not found. FSPM not available or failed to load! And I google the related information, found the gerrit review information(https://review.coreboot.org/c/coreboot/+/34423/), I want to query you how to make/create the FSP binary for AMD or FSP information to coreboot image. Could you give me some instructions? Thanks.

1 day, 12 hours

Flashing coreboot and Intel Flash Descriptor Erase Issue

by Balaji Sivakumar

We are using SPI flash(Macronix) to program the BIOS. And we use an external programmer to flash the BIOS (coreboot including FD+ME) into SPI Flash (16384 kB, SPI), it works fine and boots well. The board is functional and we have successfully booted a kernel on it. Am working on adding a feature to upgrading the BIOS (complete IFD+ME+Coreboot) using intel-spi driver at the OS level. Able to successfully take the backup full 16MB spi nor flash data which includes IFD+ME+BIOS using flashrom Internal Programmer option and it is identified as Opaque flash chip and using dd command as well. But we are seeing the erase fail through both flashrom and flash_erase utility. I believe it fails to erase at the flash descriptor location. As far as Read/Write access to the SPI regions, I have enabled the Host CPU BIOS write access and ME Master Access as 0xFFFF through Intel FIT Tool but still not able to erase it and it fails. Is there anything that could be preventing to enable read/write access to the Intel flash descriptor or any SOC SPI controller protection to access the Flash descriptor? -- Thanks, Balaji

2 days, 20 hours

IRQ routing: how to do the mainboard_picr_data/_intr_data structures?

by Mike Banon

Dear friends, I'm trying to properly program the IRQ tables for Lenovo G505S, because the old IRQ routing is bad and doesn't work for a simple OS like Kolibri. Full details are in the comments under this change: https://review.coreboot.org/c/coreboot/+/46587/ When I used the old picr_data/intr_data values of G505S for the new structures, I got only 1 IRQ working. However, with a copy-paste of AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some problems. Please advise how to compose mainboard_picr_data/_intr_data and also a intel_irq_routing_table, your help will be very much appreciated. Best regards, Mike Banon

4 days, 18 hours

New Defects reported by Coverity Scan for coreboot

by scan-admin＠coverity.com

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 1435826: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/cpu/x86/mtrr/mtrr.c: 487 in calc_var_mtrr_range() ________________________________________________________________________________________________________ *** CID 1435826: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/cpu/x86/mtrr/mtrr.c: 487 in calc_var_mtrr_range() 481 size_msb = fms64(size); 482 483 /* All MTRR entries need to have their base aligned to the mask 484 * size. The maximum size is calculated by a function of the 485 * min base bit set and maximum size bit set. */ 486 if (addr_lsb > size_msb) >>> CID 1435826: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "1 << size_msb" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 487 mtrr_size = 1 << size_msb; 488 else 489 mtrr_size = 1 << addr_lsb; 490 491 if (var_state->prepare_msrs) 492 prep_var_mtrr(var_state, base, mtrr_size, mtrr_type); ** CID 1435825: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/cpu/x86/mtrr/mtrr.c: 489 in calc_var_mtrr_range() ________________________________________________________________________________________________________ *** CID 1435825: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/cpu/x86/mtrr/mtrr.c: 489 in calc_var_mtrr_range() 483 /* All MTRR entries need to have their base aligned to the mask 484 * size. The maximum size is calculated by a function of the 485 * min base bit set and maximum size bit set. */ 486 if (addr_lsb > size_msb) 487 mtrr_size = 1 << size_msb; 488 else >>> CID 1435825: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "1 << addr_lsb" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 489 mtrr_size = 1 << addr_lsb; 490 491 if (var_state->prepare_msrs) 492 prep_var_mtrr(var_state, base, mtrr_size, mtrr_type); 493 494 size -= mtrr_size; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

5 days, 11 hours

Flashing coreboot and Intel Flash Descriptor Erase Issue

by Balaji Sivakumar

Hello Everyone, We are using SPI flash(Macronix) to program the BIOS. And we use an external programmer to flash the BIOS (coreboot including FD+ME) into SPI Flash (16384 kB, SPI), it works fine and boots well. The board is functional and we have successfully booted a kernel on it. Am working on adding a feature to upgrading the BIOS (complete IFD+ME+Coreboot) using intel-spi driver at the OS level. Able to successfully take the backup full 16MB spi nor flash data which includes IFD+ME+BIOS using flashrom Internal Programmer option and it is identified as Opaque flash chip and using dd command as well. But we are seeing the erase fail through both flashrom and flash_erase utility. I believe it fails to erase at the flash descriptor location. As far as Read/Write access to the SPI regions, I have enabled the Host CPU BIOS write access and ME Master Access as 0xFFFF through Intel FIT Tool but still not able to erase it and it fails. Is there anything that could be preventing to enable read/write access to the Intel flash descriptor or any SOC SPI controller protection to access the Flash descriptor? Any pointers would be appreciated. Thanks Balaji

6 days, 3 hours

AMD AGESA: Missing PCI bridge 00:15.2 on Asus F2A85-M PRO

by Paul Menzel

Dear coreboot folks, Trying to finish the Asus F2A85-M PRO coreboot port (AMD Family 15h/Hudson), the internal network device does not work with the state from [1]. With the vendor firmware 6601, it is 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 09) behind PCI bridge 00:15.2. > -[0000:00]-+-00.0 > +-00.2 > +-01.0 > +-01.1 > +-10.0 > +-10.1 > +-11.0 > +-12.0 > +-12.2 > +-13.0 > +-13.2 > +-14.0 > +-14.2 > +-14.3 > +-14.4-[01]-- > +-15.0-[02]-- > +-15.1-[03]----00.0 > +-15.2-[04]----00.0 > +-18.0 > +-18.1 > +-18.2 > +-18.3 > +-18.4 > \-18.5 In the current state [1], coreboot says device 00:15.2 is disabled > Show all devs... After init. > Root Device: enabled 1 > CPU_CLUSTER: 0: enabled 1 > DOMAIN: 0000: enabled 1 > APIC: 10: enabled 1 > PCI: 00:00.0: enabled 1 > PCI: 00:00.2: enabled 1 > PCI: 00:01.0: enabled 1 > PCI: 00:01.1: enabled 1 > PCI: 00:02.0: enabled 0 > PCI: 00:03.0: enabled 0 > PCI: 00:04.0: enabled 0 > PCI: 00:05.0: enabled 0 > PCI: 00:06.0: enabled 0 > PCI: 00:07.0: enabled 0 > PCI: 00:08.0: enabled 0 > PCI: 00:10.0: enabled 1 > PCI: 00:10.1: enabled 1 > PCI: 00:11.0: enabled 1 > PCI: 00:12.0: enabled 1 > PCI: 00:12.2: enabled 1 > PCI: 00:13.0: enabled 1 > PCI: 00:13.2: enabled 1 > PCI: 00:14.0: enabled 1 > PCI: 00:14.1: enabled 0 > PCI: 00:14.2: enabled 1 > PCI: 00:14.3: enabled 1 > PCI: 00:14.4: enabled 1 > PCI: 00:14.7: enabled 0 > PCI: 00:15.0: enabled 1 > PCI: 00:15.1: enabled 1 > PCI: 00:15.2: enabled 0 > PCI: 00:18.0: enabled 1 But it is enabled in the devicetree `src/mainboard/asus/f2a85-m/devicetree_f2a85-m_pro.cb`. device pci 15.2 on end # PCI bridge Please find the spew log attached. Any help is appreciated. Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/46021/ "mb/asus/f2a85-m_pro: Enable super-i/o LDNs 0x0f and 0x14"

6 days, 6 hours

Issue with BMC module

by Ale

Hello everyone, I have a kgpe d16 motherboard with coreboot and seabios, for now I have only one CPU mounted (the 2nd socket is empty) with 64 gb of ram: if I power on the PC without the BMC module, fans will spin at the maximum speed and I can see seabios and boot the OS; if I put in the BMC module with openBMC installed then fans spin at lower RPM but the seabios is not shown anymore (and, therefor, the pc cannot boot the OS). Do you have some idea of why this happens? Maybe I need 2 processor for openBMC to work fine? Thank you very much! Best regards Alessio

6 days, 9 hours

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot