coreboot

coreboot@coreboot.org

6 participants
39687 discussions

How to register on Coreboot Mainboard Vendor
by hechen42＠hotmail.com 31 May '22

31 May '22

Dear Coreboot team, Good days. We are an OEM&OEM Firewall mini pc manufacturer in SHENZHEN China. We are developing 2.5G firewall Mini PC hareware(we already finished them). And as Coreboot is very poweful and well knowned in firewall field so we are wonding that if we can become a coreboot registered motherboard vendor so user could use coreboot on our devices. May we know how to achieve its requirements ? Waitng for your comments and thanks a lot. Best Regards He Chen

2 1

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

31 May '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 1489551: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1489551: Null pointer dereferences (FORWARD_NULL) /src/cpu/x86/mp_init.c: 797 in install_permanent_handler() 791 792 printk(BIOS_DEBUG, "Installing permanent SMM handler to 0x%08lx\n", smbase); 793 794 if (smm_load_module(smbase, smsize, &smm_params)) 795 return CB_ERR; 796 >>> CID 1489551: Null pointer dereferences (FORWARD_NULL) >>> Passing "&smm_params" to "adjust_smm_apic_id_map", which dereferences null "smm_params.stub_params". 797 adjust_smm_apic_id_map(&smm_params); 798 799 return CB_SUCCESS; 800 } 801 802 /* Load SMM handlers as part of MP flight record. */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

[Proposal] Drop support for Ice lake [unmaintained]
by Tim Wawrzynczak 30 May '22

30 May '22

Good day folks, In a recent change[0], it was proposed that we drop support for the Intel Ice Lake platform. The only mainboard supporting the platform was the Intel RVP, but as far as anyone knows, it appears the project never progressed past the initial silicon, and so the code is now unmaintained and also unused. Since Ice Lake is very similar to TGL & ADL, it poses a maintenance burden when dealing with Intel common code e.g., anything in src/soc/intel/common. According to [1], this should be announced in upcoming release notes first, and removal could happen in 6 months. Wondering if anyone has any thoughts on why we should keep it around, otherwise let's update the upcoming release notes to give the "official" notice that it will be dropped. Cheers, - Tim [0]https://review.coreboot.org/c/coreboot/+/60053 [1]https://doc.coreboot.org/releases/templates.html

2 1

"vPub v5" opensource online Party! - this Thursday at 4 PM UTC
by Mike Banon 25 May '22

25 May '22

Dear friends, I'm happy to tell you about the upcoming "vPub v5" online party which starts this Thursday (26 May) at 4 PM UTC. Here's a homepage of our online party - https://vpub.dasharo.com/ Aside from having fun, we'd like to discuss and learn more about the wonderful open-source projects from the embedded world of firmware & hardware - and their advantages of liberty, security and quality. Some examples of the possible topics: *) new opensource coreboot BIOS port for a fresh retail Intel Alder Lake MSI PRO Z690-A WiFi DDR4 motherboard & its' testing results by QubesOS users. This port has been done by our 3mdeb company and is quite a spectacular accomplishment - because it's for a new motherboard still widely available as new! (usually by the time an opensource firmware is ported to some motherboard, it's long gone from the market and the people have to search for the old used ones); *) RustSBI - a software supervisor for RISC-V written on Rust programming language; *) qspimux - a hardware adapter for the safe remote flashing of SPI flash chip (used for storing the firmwares) without detaching it from a target motherboard; *) lnDSO150 - an alternative firmware for the popular handheld DSO oscilloscopes; *) bcm5719-fw - an alternative firmware for the network card Broadcom BCM5719; *) swtpm - a software Trusted Platform Module emulator and the ways of using it; *) TrenchBoot - a framework which uses multiple projects to improve the security of firmware booting. Thank you for a wonderful time with us at our past parties and your kind feedback! We hope that this one will be as exciting as the previous ones (which lasted for 10-12 hours) - and will be waiting for you. Expect a great time in a cosy community of opensource enthusiasts from all over the world! ;-) -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

Another day, another SMM loader vulnerability
by Arthur Heymans 23 May '22

23 May '22

Hi After last week's SMM loader problem on all but the BSP, I noticed another problem in the SMM setup. The permanent smihandler is currently built as a relocatable module such that coreboot can place it wherever it thinks it's a good idea. (TSEG is not known at buildtime). These relocatable modules have an alignment requirement. It looks however that the code to deal with the alignment requirement is also wrong and aligns the handler upwards instead of downwards which makes it encroach either an SSE2 FX_SAVE area or an SMM register save state. It's hard to know whether this is easily exploitable. I would think that a carefully crafted SMM save state on the right AP arbitrary code executing might be possible. On the other hand I noticed last week that launching SMM on APs is broken too so this is likely a lesser problem. Anyway the fix is in https://review.coreboot.org/c/coreboot/+/63475 (It has a comment indicating what code was causing this problem) Please review and update your coreboot code! Kind regards Arthur

2 3

Please test and review AGESA code
by Arthur Heymans 20 May '22

20 May '22

Hi We spend more time debating whether to keep AGESA in the master branch than actually reviewing code to maintains it. Here are some patches series I would like to be tested & reviewed: - Agesa was never properly linked and relied on default linker behavior to append unmatched data. Here is the fix: https://review.coreboot.org/q/topic:AGESA_DATA - Use MRC cache for non volatile data https://review.coreboot.org/q/topic:AGESA_MRC_CACHE - Use CLFLUSH to make sure code hits DRAM and incidently avoid inconsistent MTRRs (bonus is compressed postcar stage): https://review.coreboot.org/q/topic:compress_postcar Kind regards Arthur

3 4

Open Source Firmware Hackathon 2022
by Felix Singer 18 May '22

18 May '22

Hi everyone, after two crazy years, we decided it's time to do a open source firmware hackathon. It will take place from 10th June - 12th June in Darmstadt, Germany. For more details and tickets, have a look on this site [1]. The hackathon will cover open source firmware projects, like coreboot, oreboot, flashrom, LinuxBoot and any topics related to them. We have two lecture rooms (2x 80 people) for discussions and presentations. Currently, only 17 tickets are left. Everyone is welcome, no matter if beginner or professional. 24h breakfast, snacks and soft drinks are provided for free. Would love to see you there! // Felix [1] https://osfw.foundation/events/osff-summer-hackathon-2022/

1 0

[RFC] #pragma once
by Arthur Heymans 17 May '22

17 May '22

Hi To make sure headers don't create conflicts, guards are added to all of them. But the guard needs to be correct: e.g. https://review.coreboot.org/c/coreboot/+/64360/2 Most compilers implement '#pragma once ' as an alternative. Should we use this instead across the tree, as it is less error prone and less code? Sidenote: clang warns about wrong header guards. https://review.coreboot.org/c/coreboot/+/62173/23 hooks up clang to our CI for some platforms ;-). Kind regards Arthur

7 13

Re: Please test and review AGESA code
by Martin Roth 17 May '22

17 May '22

May 17, 2022, 11:40 by coreboot(a)coreboot.org: > Just my opinion, and I'm intentionally replying off list. > Oops. Or not. :-/

1 0

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

17 May '22

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. 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 5 of 5 defect(s) ** CID 1488867: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /src/cpu/x86/mtrr/earlymtrr.c: 45 in var_mtrr_set() ________________________________________________________________________________________________________ *** CID 1488867: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /src/cpu/x86/mtrr/earlymtrr.c: 45 in var_mtrr_set() 39 min base bit set and maximum size bit set. */ 40 if (addr_lsb > size_msb) 41 mtrr_size = 1 << size_msb; 42 else 43 mtrr_size = 1 << addr_lsb; 44 >>> CID 1488867: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "(uint64_t)addr >> 32" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 45 base.hi = (uint64_t)addr >> 32; 46 base.lo = addr | type; 47 mask.hi = upper_mask; 48 mask.lo = ~(mtrr_size - 1) | MTRR_PHYS_MASK_VALID; 49 ctx->mtrr[ctx->used_var_mtrrs].base = base; 50 ctx->mtrr[ctx->used_var_mtrrs].mask = mask; ** CID 1488866: (TAINTED_SCALAR) /util/amdfwtool/amdfwread.c: 121 in read_soft_fuse() /util/amdfwtool/amdfwread.c: 121 in read_soft_fuse() ________________________________________________________________________________________________________ *** CID 1488866: (TAINTED_SCALAR) /util/amdfwtool/amdfwread.c: 121 in read_soft_fuse() 115 &current_entries, &num_current_entries) != 0) 116 return 1; 117 118 while (1) { 119 uint32_t l2_dir_offset = 0; 120 >>> CID 1488866: (TAINTED_SCALAR) >>> Using tainted variable "num_current_entries" as a loop boundary. 121 for (size_t i = 0; i < num_current_entries; i++) { 122 uint32_t type = current_entries[i].type; 123 if (type == AMD_PSP_FUSE_CHAIN) { 124 uint64_t mode = current_entries[i].address_mode; 125 uint64_t addr = current_entries[i].addr; 126 uint64_t fuse = mode << 62 | addr; /util/amdfwtool/amdfwread.c: 121 in read_soft_fuse() 115 &current_entries, &num_current_entries) != 0) 116 return 1; 117 118 while (1) { 119 uint32_t l2_dir_offset = 0; 120 >>> CID 1488866: (TAINTED_SCALAR) >>> Using tainted variable "num_current_entries" as a loop boundary. 121 for (size_t i = 0; i < num_current_entries; i++) { 122 uint32_t type = current_entries[i].type; 123 if (type == AMD_PSP_FUSE_CHAIN) { 124 uint64_t mode = current_entries[i].address_mode; 125 uint64_t addr = current_entries[i].addr; 126 uint64_t fuse = mode << 62 | addr; ** CID 1488865: Integer handling issues (BAD_SHIFT) /src/cpu/x86/mtrr/earlymtrr.c: 45 in var_mtrr_set() ________________________________________________________________________________________________________ *** CID 1488865: Integer handling issues (BAD_SHIFT) /src/cpu/x86/mtrr/earlymtrr.c: 45 in var_mtrr_set() 39 min base bit set and maximum size bit set. */ 40 if (addr_lsb > size_msb) 41 mtrr_size = 1 << size_msb; 42 else 43 mtrr_size = 1 << addr_lsb; 44 >>> CID 1488865: Integer handling issues (BAD_SHIFT) >>> In expression "(uint64_t)addr >> 32", right shifting "addr" by more than 31 bits always yields zero. The shift amount is 32. 45 base.hi = (uint64_t)addr >> 32; 46 base.lo = addr | type; 47 mask.hi = upper_mask; 48 mask.lo = ~(mtrr_size - 1) | MTRR_PHYS_MASK_VALID; 49 ctx->mtrr[ctx->used_var_mtrrs].base = base; 50 ctx->mtrr[ctx->used_var_mtrrs].mask = mask; ** CID 1488864: (TAINTED_SCALAR) /util/amdfwtool/amdfwread.c: 91 in read_psp_directory() /util/amdfwtool/amdfwread.c: 92 in read_psp_directory() ________________________________________________________________________________________________________ *** CID 1488864: (TAINTED_SCALAR) /util/amdfwtool/amdfwread.c: 91 in read_psp_directory() 85 expected_cookie, header->cookie); 86 return 1; 87 } 88 89 /* Read the entries */ 90 *num_entries = header->num_entries; >>> CID 1488864: (TAINTED_SCALAR) >>> Passing tainted expression "16UL * 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.] 91 *entries = malloc(sizeof(psp_directory_entry) * header->num_entries); 92 if (fread(*entries, sizeof(psp_directory_entry), header->num_entries, fw) 93 != header->num_entries) { 94 ERR("Failed to read %d PSP entries\n", header->num_entries); 95 return 1; 96 } /util/amdfwtool/amdfwread.c: 92 in read_psp_directory() 86 return 1; 87 } 88 89 /* Read the entries */ 90 *num_entries = header->num_entries; 91 *entries = malloc(sizeof(psp_directory_entry) * header->num_entries); >>> CID 1488864: (TAINTED_SCALAR) >>> Passing tainted expression "header->num_entries" to "fread", which uses it as an offset. 92 if (fread(*entries, sizeof(psp_directory_entry), header->num_entries, fw) 93 != header->num_entries) { 94 ERR("Failed to read %d PSP entries\n", header->num_entries); 95 return 1; 96 } 97 ** CID 1488863: (RESOURCE_LEAK) /util/amdfwtool/amdfwread.c: 129 in read_soft_fuse() /util/amdfwtool/amdfwread.c: 152 in read_soft_fuse() /util/amdfwtool/amdfwread.c: 116 in read_soft_fuse() /util/amdfwtool/amdfwread.c: 129 in read_soft_fuse() ________________________________________________________________________________________________________ *** CID 1488863: (RESOURCE_LEAK) /util/amdfwtool/amdfwread.c: 129 in read_soft_fuse() 123 if (type == AMD_PSP_FUSE_CHAIN) { 124 uint64_t mode = current_entries[i].address_mode; 125 uint64_t addr = current_entries[i].addr; 126 uint64_t fuse = mode << 62 | addr; 127 128 printf("Soft-fuse:0x%lx\n", fuse); >>> CID 1488863: (RESOURCE_LEAK) >>> Variable "current_entries" going out of scope leaks the storage it points to. 129 return 0; 130 } else if (type == AMD_FW_L2_PTR) { 131 /* There's a second level PSP directory to read */ 132 if (l2_dir_offset != 0) 133 return 1; 134 /util/amdfwtool/amdfwread.c: 152 in read_soft_fuse() 146 /* Read the L2 PSP directory */ 147 if (read_psp_directory(fw, l2_dir_offset, PSPL2_COOKIE, &header, 148 &current_entries, &num_current_entries) != 0) 149 break; 150 } 151 >>> CID 1488863: (RESOURCE_LEAK) >>> Variable "current_entries" going out of scope leaks the storage it points to. 152 return 1; 153 } 154 155 enum { 156 AMDFW_OPT_HELP = 'h', 157 /util/amdfwtool/amdfwread.c: 116 in read_soft_fuse() 110 else 111 psp_offset = fw_header->new_psp_directory; 112 113 psp_directory_header header; 114 if (read_psp_directory(fw, psp_offset, PSP_COOKIE, &header, 115 &current_entries, &num_current_entries) != 0) >>> CID 1488863: (RESOURCE_LEAK) >>> Variable "current_entries" going out of scope leaks the storage it points to. 116 return 1; 117 118 while (1) { 119 uint32_t l2_dir_offset = 0; 120 121 for (size_t i = 0; i < num_current_entries; i++) { /util/amdfwtool/amdfwread.c: 129 in read_soft_fuse() 123 if (type == AMD_PSP_FUSE_CHAIN) { 124 uint64_t mode = current_entries[i].address_mode; 125 uint64_t addr = current_entries[i].addr; 126 uint64_t fuse = mode << 62 | addr; 127 128 printf("Soft-fuse:0x%lx\n", fuse); >>> CID 1488863: (RESOURCE_LEAK) >>> Variable "current_entries" going out of scope leaks the storage it points to. 129 return 0; 130 } else if (type == AMD_FW_L2_PTR) { 131 /* There's a second level PSP directory to read */ 132 if (l2_dir_offset != 0) 133 return 1; 134 ________________________________________________________________________________________________________ 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