coreboot

coreboot@coreboot.org

6 participants
39687 discussions

Universal Payload - RFC and Invitation from Universal Payload community
by Banik, Subrata 05 Nov '20

05 Nov '20

HI All, coreboot is a modular design with hardware initialization stage followed by a payload to boot OS https://doc.coreboot.org/payloads.html There is a new initiative to standardize the bootloader to payload interface. The initiative is called Universal Payload project and details can be found @ https://github.com/universalpayload/Introduction The goal for this initiative is interoperability between bootloaders and payloads so that different bootloaders can work with different payloads. An early draft of the spec can be found @ https://universalpayload.github.io/documentation/spec/spec.html. The Universal Payload community welcomes feedback and contributions. We are developing various POC codes to demonstrate the concept. One POC uses coreboot as the bootloader and EDKII UEFI as the payload https://github.com/universalpayload/coreboot/tree/universal_payload Thanks, Subrata

4 4

Coreboot Hardware
by nirmalarasu＠hotmail.com 02 Nov '20

02 Nov '20

Hi all, I am a newbie for coreboot development . I am looking for open source hardware where i can debug and play around with coreboot features. Any recommendation for debug capable hardware which available in market? -Arun

1 0

Convenient payload development part 1: QEMU Make targets
by Nico Huber 01 Nov '20

01 Nov '20

Hi folks, I'm currently looking into making payload builds and testing more convenient. That involves, among other things, QEMU make targets with default options that should ease coreboot development, incre- mental builds of payloads, support for local changes in payload dirs. So far I've finished the QEMU hook-up for x86 targets [1]. The idea is to have a Make target `qemu` that is automatically added if a com- patible coreboot target is selected. With some luck, adding more coreboot targets should be as easy as specifying the QEMU binary to use, e.g. QEMU-$(CONFIG_BOARD_EMULATION_...) ?= qemu-system-... What I only learned recently: QEMU supports configuration files that ease adding specific devices to emulate (compared to ever growing command lines). I wrote one for the Intel Q35 emulation target [2] with most of the (PCI) devices one would expect with that chipset. This should help to test in an environment that comes closer to real boards. Comments and review welcome! Cheers, Nico [1] https://review.coreboot.org/c/coreboot/+/46767 [2] https://review.coreboot.org/c/coreboot/+/46768

1 0

amd_blobs submodule update issue when using git sup alias and how to fix it
by Felix Held 29 Oct '20

29 Oct '20

Hi! Quick heads-up: In [1] I updated the submodule pointer of amd_blobs so that it now tracks the new official repository [2]. Since the new repository and the old don't have common ancestors, using the git sup alias to update the submodules, that rebases the changes, will fail causing git to fall back to a 3 way merge. Since the new repository contains updated firmware blobs, that merge also fails. To fix the issue run the following commands: (cd 3rdparty/amd_blobs; git rebase --abort); git submodule update --checkout Regards Felix [1] https://review.coreboot.org/c/coreboot/+/46594/ [2] https://github.com/amd/firmware_binaries

1 0

Universal Payload Project
by Paul Menzel 29 Oct '20

29 Oct '20

Dear coreboot, GRUB, and SeaBIOS folks, In #coreboot(a)irc.freenode.net somebody mentioned the Universal Payload Project [1]. > The goal of this project is to define an interface between a first > stage platform initialization bootloader and a second stage payload. As there also is a specification [2], I just wanted to make you aware of it, in case you have comments. Please keep in mind, that I do not know more details, so please do not jump to conclusions. Kind regards, Paul [1]: https://github.com/universalpayload/Introduction [2]: https://universalpayload.github.io/documentation/spec/spec.html

1 0

[RFC] Change in CBFS "stage" binary format
by Julius Werner 29 Oct '20

29 Oct '20

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.

1 0

[RFC] Replace strapping entries in coreboot table
by Tim Wawrzynczak 29 Oct '20

29 Oct '20

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

5 14

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

27 Oct '20

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 0

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

23 Oct '20

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…

1 0

Issue with BMC module
by Ale 22 Oct '20

22 Oct '20

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

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