coreboot

coreboot@coreboot.org

6 participants
39686 discussions

Fwd: Re: [RFC] POC: Use FDT as payload handoff instead lb_tables
by Arthur Heymans 09 Nov '22

09 Nov '22

Forgot to add coreboot(a)coreboot.org in cc. ---------- Forwarded message --------- From: Arthur Heymans <arthur(a)aheymans.xyz> Date: Wed, Nov 9, 2022 at 6:41 PM Subject: Re: [coreboot] Re: [RFC] POC: Use FDT as payload handoff instead lb_tables To: ron minnich <rminnich(a)gmail.com> I think it is possible that, over a few years, we might see fdt replace > coreboot tables. It might be a natural evolution. > If you go with the stage approach, it will never happen. We'll always need > coreboot tables as input to the fdt stage. > > I'm not seeing a natural evolution happening anytime soon. There really isn't a good enough technical reason to replace coreboot tables. If those 2 solutions live side by side in the same stage it will 100% end up in a case of https://xkcd.com/927/ > I think the stage is the wrong way to go. I want it to be possible to have > the option to build without coreboot tables. > This is more messy than you might think. A lot of code that is used in creating data structures to create coreboot tables would need to be rewritten to fit the needs to just generate FDT. https://review.coreboot.org/c/coreboot/+/68768 is one example. In the end it also boiled down to parsing a coreboot table entry struct into FDT. So if creating an FDT handoff boils down to parsing coreboot table structures even when implemented in ramstage, I don't see good arguments why it cannot live in a separate stage, as you effectively end up needing both data structures. Or is avoiding consuming a few 100's of bytes for the coreboot tables really worth it? Creating FDT handoff == parsing coreboot tables anyway, whether it lives in ramstage or separate stage... > To some extent I think the stage mechanism is overused. In fact, in > oreboot, we removed stages. > I agree and I removed some from coreboot ( https://review.coreboot.org/c/coreboot/+/55068), but in this case I could see a separate payload/stage as a good way to separate 2 things trying to achieve the same purpose. Maintaining both solutions in the same program is messy and something I'd like to avoid. Another advantage is that you don't need to rebuild coreboot to generate your needed handoff if you change payloads. If I want to change out the EDK2 FDT payload with a LinuxBoot added with cbfstool, that will just work. With FDT/coreboot tables behind Kconfig it won't. Arthur On Wed, Nov 9, 2022 at 5:07 PM ron minnich <rminnich(a)gmail.com> wrote: > I think it is possible that, over a few years, we might see fdt replace > coreboot tables. It might be a natural evolution. > If you go with the stage approach, it will never happen. We'll always need > coreboot tables as input to the fdt stage. > > I think the stage is the wrong way to go. I want it to be possible to have > the option to build without coreboot tables. > > To some extent I think the stage mechanism is overused. In fact, in > oreboot, we removed stages. > > On Tue, Nov 8, 2022 at 11:48 PM Arthur Heymans <arthur(a)aheymans.xyz> > wrote: > >> >>> So just to be clear, to make sure we weren't taking different things >>> away from that meeting: I said I'm okay with adding the FDT option as >>> a separate, isolated compile-time option for those that want to try it >>> out. But I care that the coreboot tables continue to be supported on >>> equal footing in the long term, and I don't want there to be some >>> pre-formed understanding that they'll be "deprecated eventually" or >>> that payloads will be slowly pressured to move to the FDT handoff, >>> particularly not with any specific timeline attached. >>> >>> With this in mind I don't see any reasons why generating the FDT handoff >> needs to happen in the coreboot ramstage. >> A libpayload based payload could just as well generate that FDT handoff >> and chainload the next payload. >> All the infrastructure is there in libpayload to cleanly do this. >> The coreboot code for dealing with FDT is exactly the same as deptcharge >> code (it comes from that project). >> This is a better technical solution than to introduce new Kconfig guarded >> code and maintenance overhead inside the coreboot tree to maintain 2 >> solutions for the same problem. >> As a matter of fact that solution is even more 'universal' as you could >> still swap out payloads without recompiling the coreboot part of things. >> >> Arthur >> >> On Tue, Nov 8, 2022 at 11:55 PM Julius Werner <jwerner(a)chromium.org> >> wrote: >> >>> > As mentioned by Julius, we had a candid discussion yesterday on this, >>> while he still reserves his opinions on FDT, he will not block the >>> implementation. For now we will guard it with kconfig and give it a year of >>> trial to see how it turns out. >>> >>> So just to be clear, to make sure we weren't taking different things >>> away from that meeting: I said I'm okay with adding the FDT option as >>> a separate, isolated compile-time option for those that want to try it >>> out. But I care that the coreboot tables continue to be supported on >>> equal footing in the long term, and I don't want there to be some >>> pre-formed understanding that they'll be "deprecated eventually" or >>> that payloads will be slowly pressured to move to the FDT handoff, >>> particularly not with any specific timeline attached. >>> >>

1 0

[patch] x11ssh-f hanging in fsp, probably IGD init
by Valentin Kleibel 08 Nov '22

08 Nov '22

Hi, After some failures i was successful booting coreboot on a supermicro x11ssh-f [CPU: Xeon E3-1220 v5]. Built from the most recent git coreboot hangs indefinitely at: > [DEBUG] BS: BS_DEV_INIT_CHIPS entry times (exec / console): 283 / 381 ms > [DEBUG] IA32_FEATURE_CONTROL status: locked > [INFO ] POST: 0x71 > [DEBUG] WEAK: src/soc/intel/skylake/chip.c/mainboard_silicon_init_params called > [ERROR] Null dereference at eip: 0x7f317e15 > [INFO ] POST: 0x93 We noticed the proposed change https://review.coreboot.org/c/coreboot/+/51332 from over a year ago and updated the patch. The attached igd_disabled.patch applies cleanly on the current tree and built with the attached config the board boots as expected incl. video out via AST2400. (This was our final config, previous tests were done without mecleaner) Maybe this helps someone to get coreboot running or a fix could be applied upstream. Cheers, Valentin

1 0

[coreboot - Feature #435] (New) Add the new memtest86+ v6.0 as secondary coreboot payload
by akjuxr3 akjuxr3 07 Nov '22

07 Nov '22

Issue #435 has been reported by akjuxr3 akjuxr3. ---------------------------------------- Feature #435: Add the new memtest86+ v6.0 as secondary coreboot payload https://ticket.coreboot.org/issues/435 * Author: akjuxr3 akjuxr3 * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-25 * Related links: https://github.com/memtest86plus/memtest86plus https://www.memtest.org/ https://www.phoronix.com/news/memtest86-6.0-Released ---------------------------------------- Memtest86+ have been rewritten. The release of the final version 6.0 was on 23.10.2022 . Here the changelog: Rewrite code for UEFI 32 & 64 bits Add support for x64 Long Mode Paging Add support for up to 256 cores Add detection for DDR4 & DDR5 Add support for XMP 3.0 Add detection for AMD Zen 1/2/3/4 Add detection for Intel up to 13th Gen Add better support for AMD pre-ZEN CPUs Add support for older nVidia and AMD chipsets Add support for SDRAM Many enhancements Numerous bug fixes & optimization Since it work now with uefi, it would be great if it could be used with tianocore payload. -- 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

3 2

Please test coreboot using laptops with kernel 6.1-rc# for a possible backlight regression
by Hans de Goede 03 Nov '22

03 Nov '22

Hi All, I have landed a large(ish) refactor of the ACPI/x86 backlight detection code in the kernel for 6.1. It has come to my attention that this may cause backlight control to stop working on laptops where the original BIOS has been replaced with coreboot, see this patch, which is the root cause of the possible regression + its replies: https://lore.kernel.org/platform-driver-x86/20220825143726.269890-3-hdegoed… On ACPI/x86 laptops there may be multiple methods available to control the backlight (native GPU control, ACPI video bus, vendor specific) and even though a method is available it does not always work, basically the only method guaranteed to work is the one preferred by the Windows version with which the laptop shipped. The kernel so far has delegated part of this problem by registering multiple backlight devices under /sys/class/backlight and then letting userspace figure it out. One goal of the refactor is to only register 1 backlight device per panel. On many (somewhat older) laptops "ls /sys/class/backlight" would show 2 backlight devices: "acpi_video0" and "intel_backlight" and the various (per desktop) userspace backlight helpers would prefer the "acpi_video0". The goal of the linked kernel patch is to simply not register "intel_backlight" in this case, just like the kernel was already not registering "acpi_video0" on the models where "intel_backlight" should be used. But this may cause problems / a change in behavior if: 1. You have an unusual / or customized userspace which prefers intel_backlight over acpi_video0 when both are present 2. You always only had intel_backlight and that now no longer gets registered, leaving you completely without backlight support. I would like to try and find and resolve any such problems before 6.1 gets released. As such if you are using a laptop with coreboot please run the following tests: 1. Boot kernel 6.0 or older, and collect the output of: ls /sys/class/backlight 2. Boot kernel 6.1, note for ChromeBooks please used Torvalds latest master and not rc2 since a fix for ChromeBooks has just landed, and collect the output of: ls /sys/class/backlight 3. Check if everything still works as expected with kernel 6.1 Report the results of 1-3 either on the list or in a direct email to me (your choice). Please include the model of your laptop and please report this even if everything still works fine, I need to know how things work on coreboot laptops which have not regressed too, to avoid accidentally regressing those if I need to do fixes for some other coreboot capable models. 4. Run: sudo dmidecode > dmidecode.txt sudo acpidump -o acpidump.txt And then send me a *private* off-list email with the dmidecode.txt and acpidump.txt files attached. Please don't forget to mention the model of your laptop in this email. Sorry for any breakage my backlight refactor may have caused and thank you in advance for taking the time to test this. Regards, Hans

5 9

Creating a coreboot Security team
by coreboot org 03 Nov '22

03 Nov '22

Hi everyone, At one of the last coreboot leadership meetings, the idea of a coreboot security team was brought up. We'd like to build a group to look at coreboot's source code with an eye on security, respond to issues on the security mailing list, help fix security-related issues, and shepherd security related patches through gerrit. Additionally we'd like upcoming features to go through this group to look for possible security issues. This team would preferably be a mix of some of the senior coreboot developers, firmware/software security researchers, and industry professionals. I know that many of the companies working on coreboot have dedicated security teams. It would be great if a couple of these companies could be convinced to assign individuals to spend a few hours a week on the coreboot project. If anyone would be interested in being on this team, or knows someone who would be good in this role, please reach out. Thanks. Martin

2 1

regarding build failure due to SHA api added in amdfwtools
by ritul guru 02 Nov '22

02 Nov '22

Hi, I am getting build below error, any pre-req to get SHA256 definitions? /usr/bin/ld: build/util/amdfwtool/amdfwtool.o: in function `add_single_sha': /amd/src/coreboot/util/amdfwtool/amdfwtool.c:685: undefined reference to `SHA256' /usr/bin/ld: /amd/src/coreboot/util/amdfwtool/amdfwtool.c:682: undefined reference to `SHA384' collect2: error: ld returned 1 exit status make: *** [util/amdfwtool/Makefile.inc:19: build/util/amdfwtool/amdfwtool] Error 1 *Thanks & RegardsRitul Guru+91-9916513186*

3 7

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

01 Nov '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. 4 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 1 of 1 defect(s) ** CID 1500400: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1500400: Null pointer dereferences (NULL_RETURNS) /src/mainboard/google/dedede/smihandler.c: 76 in mainboard_config_cbi_wp() 70 * HW WP | SW WP | CBI WP 71 * ------|-------|------- 72 * 0 | X | 0 73 * 1 | 0 | 0 74 * 1 | 1 | 1 75 */ >>> CID 1500400: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "spi_flash_dev" when calling "spi_flash_status". 76 if (spi_flash_status(spi_flash_dev, &sr1) < 0) { 77 printk(BIOS_ERR, "MB: Failed to read SPI status register 1\n"); 78 printk(BIOS_ERR, "MB: CBI EEPROM WP cannot change!"); 79 return; 80 } 81 ________________________________________________________________________________________________________ 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 28 Oct '22

28 Oct '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 6 new defect(s) introduced to coreboot found with Coverity Scan. 3 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 6 of 6 defect(s) ** CID 1500223: (TAINTED_SCALAR) /util/amdfwtool/amdfwread.c: 140 in read_bios_directory() /util/amdfwtool/amdfwread.c: 141 in read_bios_directory() ________________________________________________________________________________________________________ *** CID 1500223: (TAINTED_SCALAR) /util/amdfwtool/amdfwread.c: 140 in read_bios_directory() 134 header->cookie, expected_cookie); 135 return 1; 136 } 137 138 /* Read the entries */ 139 *num_entries = header->num_entries; >>> CID 1500223: (TAINTED_SCALAR) >>> Passing tainted expression "24UL * header->num_entries" to "malloc", which uses it as an allocation size. [Note: The source code implementation of the function has been overridden by a builtin model.] 140 *entries = malloc(sizeof(bios_directory_entry) * header->num_entries); 141 if (fread(*entries, sizeof(bios_directory_entry), header->num_entries, fw) 142 != header->num_entries) { 143 ERR("Failed to read %d BIOS entries\n", header->num_entries); 144 return 1; 145 } /util/amdfwtool/amdfwread.c: 141 in read_bios_directory() 135 return 1; 136 } 137 138 /* Read the entries */ 139 *num_entries = header->num_entries; 140 *entries = malloc(sizeof(bios_directory_entry) * header->num_entries); >>> CID 1500223: (TAINTED_SCALAR) >>> Passing tainted expression "header->num_entries" to "fread", which uses it as an offset. 141 if (fread(*entries, sizeof(bios_directory_entry), header->num_entries, fw) 142 != header->num_entries) { 143 ERR("Failed to read %d BIOS entries\n", header->num_entries); 144 return 1; 145 } 146 ** CID 1500222: Control flow issues (DEADCODE) /src/soc/mediatek/mt8188/ddp.c: 103 in main_disp_path_setup() ________________________________________________________________________________________________________ *** CID 1500222: Control flow issues (DEADCODE) /src/soc/mediatek/mt8188/ddp.c: 103 in main_disp_path_setup() 97 static void main_disp_path_setup(u32 width, u32 height, u32 vrefresh) 98 { 99 u32 idx; 100 const u32 pixel_clk = width * height * vrefresh; 101 102 for (idx = 0; idx < MAIN_PATH_OVL_NR; idx++) { >>> CID 1500222: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "0U" inside this statement: "ovl_set_roi(idx, width, hei...". 103 ovl_set_roi(idx, width, height, idx ? 0 : 0xff0000ff); 104 ovl_layer_smi_id_en(idx); 105 ovl_layer_gclast_en(idx); 106 ovl_layer_output_clamp_en(idx); 107 ovl_layer_en(idx); 108 } ** CID 1500221: Insecure data handling (TAINTED_SCALAR) /util/amdfwtool/amdfwread.c: 260 in amdfw_bios_dir_walk() ________________________________________________________________________________________________________ *** CID 1500221: Insecure data handling (TAINTED_SCALAR) /util/amdfwtool/amdfwread.c: 260 in amdfw_bios_dir_walk() 254 255 if (read_bios_directory(fw, bios_offset, cookie, &header, 256 &current_entries, &num_current_entries) != 0) 257 return 1; 258 259 do_indentation_string(indent, level); >>> CID 1500221: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "num_current_entries" as a loop boundary. 260 for (size_t i = 0; i < num_current_entries; i++) { 261 uint32_t type = current_entries[i].type; 262 uint64_t mode = current_entries[i].address_mode; 263 uint64_t addr = current_entries[i].source; 264 265 if (type == AMD_BIOS_APOB || type == AMD_BIOS_PSP_SHARED_MEM) ** CID 1500220: Resource leaks (RESOURCE_LEAK) /util/amdfwtool/amdfwread.c: 312 in amdfw_psp_dir_walk() ________________________________________________________________________________________________________ *** CID 1500220: Resource leaks (RESOURCE_LEAK) /util/amdfwtool/amdfwread.c: 312 in amdfw_psp_dir_walk() 306 uint32_t ish_dir_offset = 0; 307 ish_directory_table ish_dir; 308 char indent[MAX_INDENTATION_LEN] = {0}; 309 310 if (read_psp_directory(fw, psp_offset, cookie, &header, 311 &current_entries, &num_current_entries) != 0) >>> CID 1500220: Resource leaks (RESOURCE_LEAK) >>> Variable "current_entries" going out of scope leaks the storage it points to. 312 return 1; 313 314 do_indentation_string(indent, level); 315 for (size_t i = 0; i < num_current_entries; i++) { 316 uint32_t type = current_entries[i].type; 317 uint64_t mode = current_entries[i].address_mode; ** CID 1500219: Insecure data handling (TAINTED_SCALAR) /util/amdfwtool/amdfwread.c: 315 in amdfw_psp_dir_walk() ________________________________________________________________________________________________________ *** CID 1500219: Insecure data handling (TAINTED_SCALAR) /util/amdfwtool/amdfwread.c: 315 in amdfw_psp_dir_walk() 309 310 if (read_psp_directory(fw, psp_offset, cookie, &header, 311 &current_entries, &num_current_entries) != 0) 312 return 1; 313 314 do_indentation_string(indent, level); >>> CID 1500219: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "num_current_entries" as a loop boundary. 315 for (size_t i = 0; i < num_current_entries; i++) { 316 uint32_t type = current_entries[i].type; 317 uint64_t mode = current_entries[i].address_mode; 318 uint64_t addr = current_entries[i].addr; 319 320 if (type == AMD_PSP_FUSE_CHAIN) ** CID 1500218: Resource leaks (RESOURCE_LEAK) /util/amdfwtool/amdfwread.c: 257 in amdfw_bios_dir_walk() ________________________________________________________________________________________________________ *** CID 1500218: Resource leaks (RESOURCE_LEAK) /util/amdfwtool/amdfwread.c: 257 in amdfw_bios_dir_walk() 251 bios_directory_hdr header; 252 uint32_t l2_dir_offset = 0; 253 char indent[MAX_INDENTATION_LEN] = {0}; 254 255 if (read_bios_directory(fw, bios_offset, cookie, &header, 256 &current_entries, &num_current_entries) != 0) >>> CID 1500218: Resource leaks (RESOURCE_LEAK) >>> Variable "current_entries" going out of scope leaks the storage it points to. 257 return 1; 258 259 do_indentation_string(indent, level); 260 for (size_t i = 0; i < num_current_entries; i++) { 261 uint32_t type = current_entries[i].type; 262 uint64_t mode = current_entries[i].address_mode; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

MrChromebox coreboot 4.18-based community release is out
by Matt DeVillier 25 Oct '22

25 Oct '22

Greetings all! I've just now posted my MrChromebox-4.18 release, which currently supports over 100 unique devices spanning a dozen platforms. A full list of supported devices can be found at https://mrchromebox.tech/#devices. Beside updating the base coreboot code, this release as usual is full of fixes and improvements: * Added support for coolstar's upcoming Windows audio drivers for Skylake, Kabylake, Apollolake, and Geminilake platform devices * Fixed extraneous microphone channels picking up noise when recording (multi) * updated Tianocore/edk2 using branch upp_202210 * Improved boot-time USB detection in Tianocore * Fixed CR50 TPM init on devices with an I2C CR50 TPM * Fixed Windows BSOD/ACPI BIOS ERROR on a handful of devices * Updated CPU microcode for all devices to latest available Beta images are available upon request for newer boards using Tigerlake, Jasperlake, or Alderlake SoCs and AMD Zen+/Picasso (just don't ask me how well they run Windows -- that's coolstar's domain). As usual, the full list of changes can be found on my github repos: https://github.com/MrChromebox/coreboot/commits/2022.10.24 https://github.com/MrChromebox/edk2/commits/upp_202210 https://github.com/MrChromebox/chrome-ec/branches/all cheers, Matt

1 0

Join coreboot Security team
by Ivan Kuzneczov 24 Oct '22

24 Oct '22

Hi all, After reading https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/7N4A… , as a software security researcher, I am interested in the planning coreboot Security team. How can I join it? Thanks. Ivan Kuzneczov

2 1

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