coreboot February 2021

coreboot@coreboot.org

42 participants
35 discussions

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 26 Feb '21

26 Feb '21

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. 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 1 of 1 defect(s) ** CID 1447050: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /src/northbridge/intel/haswell/northbridge.c: 301 in mc_add_dram_resources() ________________________________________________________________________________________________________ *** CID 1447050: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /src/northbridge/intel/haswell/northbridge.c: 301 in mc_add_dram_resources() 295 size_k = (0xa0000 >> 10) - base_k; 296 ram_resource(dev, index++, base_k, size_k); 297 298 /* 0xc0000 -> TSEG - DPR */ 299 base_k = 0xc0000 >> 10; 300 size_k = (unsigned long)(mc_values[TSEG_REG] >> 10) - base_k; >>> CID 1447050: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "dpr.size >> 10" is 0 regardless of the values of its operands. This occurs as the operand of assignment. 301 size_k -= dpr.size >> 10; 302 ram_resource(dev, index++, base_k, size_k); 303 304 /* TSEG - DPR -> BGSM */ 305 resource = new_resource(dev, index++); 306 resource->base = mc_values[TSEG_REG] - dpr.size; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Announcing our new job board
by Patrick Georgi 26 Feb '21

26 Feb '21

Hi everybody, In our leadership meetings we repeatedly had companies using coreboot look for qualified staff. In response this created a job site at coreboot.org, linked prominently from our landing page, accessible at https://coreboot.org/jobs.html So if you're looking for a coreboot related job, check out these job postings and if you're with a company that is looking for new folks, feel free to push a change to our homepage.git repository to add your company there! Best regards, Patrick Georgi -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

Intel CBnT tooling and dealing with NDA
by Arthur Heymans 23 Feb '21

23 Feb '21

Hi To make Intel CBnT (Converged Bootguard and TXT) useful in coreboot some tooling is required to generate both a Key Manifest (A signed binary, that is checked against a key fused into the ME, holding keys that OEM can use to sign the BPM) and a Boot Policy Manifest (signed binary, has a digest of IBBs, Initial Boot Blocks). At the moment these are included as binaries by the build system. Obviously this only works if the IBB hasn't changed. If it changed, you'd need to regenerate the BPM. 9elements has written some open source tooling (BSD-3 clause) to generate both KM and BPM. The code for this tool is not yet public as it was written using NDA documentation. Intel is currently reviewing this to allow us to make it public, but this takes time. It will be part of the 3rdparty/intel-sec-tools submodule. My question to the community is if it would be ok to allow for the build system integration code for KM and BPM generation to be integrated into the master branch before the code to the tooling is made public. CBnT is an optional feature on Intel hardware and is implemented as an optional feature in coreboot. The tool is standalone and coreboot can still be built fine without it. At the moment coreboot has code for xeon_sp in the master branch without a public FSP too, with the promise that it will be publicly released later on by Intel. Compared to that the situation would be a little better: we propose to add a binary tool (it's written in go so it's automatically build as a static binary) to the blobs repo under a licence similar to the one used for Intel FSP and MCU (allows redistribution). We hope to remove it ASAP from there and build it from source from 3rdparty/intel-sec-tools. We'd like to develop as close as possible to the coreboot master branch, so we hope that this is an acceptable solution to the community. So TL;DR: - Is (temporarily) adding a tool to the blobs repo ok? - Is integrating an (optional) not yet open tool into the build system ok? Let me know what you think. Kind regards. Arthur Heymans 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: arthur.heymans(a)9elements.com Phone: +49 234 68 94 188 Mobile: +32 478499445 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebastian Deutsch, Eray Basar Datenschutzhinweise nach Art. 13 DSGVO

9 17

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

23 Feb '21

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1447013: Memory - corruptions (OVERRUN) /tests/lib/memchr-test.c: 72 in test_memchr_last_character_in_string() ________________________________________________________________________________________________________ *** CID 1447013: Memory - corruptions (OVERRUN) /tests/lib/memchr-test.c: 72 in test_memchr_last_character_in_string() 66 67 static void test_memchr_last_character_in_string(void **state) 68 { 69 void *v1 = memchr(test_data1, '9', test_data1_sz); 70 void *v2 = memchr(&test_data1[test_data1_sz - 2], '9', test_data1_sz); 71 void *v3 = memchr(test_data2, 0xff, test_data2_sz); >>> CID 1447013: Memory - corruptions (OVERRUN) >>> Overrunning buffer pointed to by "&test_data2[255UL]" of 256 bytes by passing it to a function which accesses it at byte offset 510 using argument "256UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 72 void *v4 = memchr(&test_data2[test_data2_sz - 1], 0xff, test_data2_sz); 73 74 assert_ptr_equal(v1, v2); 75 assert_ptr_equal(v1, &test_data1[test_data1_sz - 2]); 76 77 assert_ptr_equal(v3, v4); ** CID 1447012: Memory - corruptions (OVERRUN) /tests/lib/memchr-test.c: 50 in test_memchr_existing_value() ________________________________________________________________________________________________________ *** CID 1447012: Memory - corruptions (OVERRUN) /tests/lib/memchr-test.c: 50 in test_memchr_existing_value() 44 static const size_t test_data2_sz = sizeof(test_data2); 45 46 static void test_memchr_existing_value(void **state) 47 { 48 /* Test using character string */ 49 void *v1 = memchr(test_data1, 'A', test_data1_sz); >>> CID 1447012: Memory - corruptions (OVERRUN) >>> Overrunning buffer pointed to by "test_data1 + 26" of 63 bytes by passing it to a function which accesses it at byte offset 78 using argument "53UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 50 void *v2 = memchr(test_data1 + 26, 'A', test_data1_sz - 10); 51 52 assert_non_null(v1); 53 assert_non_null(v2); 54 assert_ptr_equal(v1, v2); 55 assert_ptr_equal(v1, &test_data1[26]); ** CID 1447011: Memory - corruptions (OVERRUN) /tests/lib/memchr-test.c: 70 in test_memchr_last_character_in_string() ________________________________________________________________________________________________________ *** CID 1447011: Memory - corruptions (OVERRUN) /tests/lib/memchr-test.c: 70 in test_memchr_last_character_in_string() 64 assert_ptr_equal(v1, &test_data2[0x33]); 65 } 66 67 static void test_memchr_last_character_in_string(void **state) 68 { 69 void *v1 = memchr(test_data1, '9', test_data1_sz); >>> CID 1447011: Memory - corruptions (OVERRUN) >>> Overrunning buffer pointed to by "&test_data1[61UL]" of 63 bytes by passing it to a function which accesses it at byte offset 123 using argument "63UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 70 void *v2 = memchr(&test_data1[test_data1_sz - 2], '9', test_data1_sz); 71 void *v3 = memchr(test_data2, 0xff, test_data2_sz); 72 void *v4 = memchr(&test_data2[test_data2_sz - 1], 0xff, test_data2_sz); 73 74 assert_ptr_equal(v1, v2); 75 assert_ptr_equal(v1, &test_data1[test_data1_sz - 2]); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

coreboot nvme support
by Claus Stenzel 23 Feb '21

23 Feb '21

Hello coreboot team, i've got two questions concerning coreboot. 1. Does coreboot support the nvme protocol? and 2. The Lenovo T510 isn't listed in the category of the supported machines. Is it foreseeable, when the T510 will be supported? Pleased about your answer, i remain with the best wishes for the new year claus Stenzel

2 1

Regarding GSoC 2020
by vedantparanjape160201＠gmail.com 22 Feb '21

22 Feb '21

Hi, I am interested to apply to gsoc2020, is coreboot going to apply in gsoc 2021? Regards, Vedant Paranjape

4 5

GSoC query
by Hritik Vijay 22 Feb '21

22 Feb '21

Hi Coreboot appeared last year in the GSoC initiative, I wanted to know if there are plans to appear again? From the terminal Hritik Vijay Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 2

[RFC] Coding Style: Chain-includes, style questions not defined in the guide and cleanup patches
by Julius Werner 20 Feb '21

20 Feb '21

Hi, I recently landed a coding style change to define some rules about how #include directives should be written and when it's okay to "chain-include" a header, because this has been a frequent topic of discussion and cleanup patches in the past year(s) and people seemed to keep having different opinions about it. The patch caused a bit more of a stir than I anticipated because not everyone saw it before going in -- apologies for not circulating it more widely before. If you are interested in the topic, please join the discussion on https://review.coreboot.org/50247 and I'll try to write a fixup patch for it once we can clarify some consensus (contention seems to be mostly about whether headers should be alphabetized or not right now). However, in the course of that we also got into a more general discussion about "cleanup patches" and when it should be okay to write them (because sometimes people try to "clean up" things that other people intentionally wrote that way and that tends to cause some contention). I've uploaded a new coding style change about this as https://review.coreboot.org/c/coreboot/+/50966 which is trying to define some ground rules for this (and for how the style guide should be applied in general). The gist of it is that I think "cleanup patches" should focus on the things that are actually defined in the coding style, and for the things that aren't we should generally aim to honor the original author's intentions and not "bulk clean" existing files. If there are things in existing files that we think are worth cleaning up, we should first find some consensus about what is wrong with them and put a rule about that in the coding style, so that different people don't keep "cleaning up" the existing codebase to their personal preferences which keeps pulling it in different directions. If you're interested in this topic please join the discussion on Gerrit and let me know what you think. Thanks, Julius

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 19 Feb '21

19 Feb '21

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 4 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 4 of 4 defect(s) ** CID 1446761: Control flow issues (DEADCODE) /src/lib/cbmem_common.c: 14 in cbmem_run_init_hooks() ________________________________________________________________________________________________________ *** CID 1446761: Control flow issues (DEADCODE) /src/lib/cbmem_common.c: 14 in cbmem_run_init_hooks() 8 cbmem_init_hook_t *init_hook_ptr = 9 (cbmem_init_hook_t *)&_cbmem_init_hooks; 10 cbmem_init_hook_t *einit_hook_ptr = 11 (cbmem_init_hook_t *)&_ecbmem_init_hooks; 12 13 if (REGION_SIZE(cbmem_init_hooks) == 0) >>> CID 1446761: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return;". 14 return; 15 16 while (init_hook_ptr != einit_hook_ptr) { 17 (*init_hook_ptr)(is_recovery); 18 init_hook_ptr++; 19 } ** CID 1446760: Resource leaks (RESOURCE_LEAK) /tests/lib/memset-test.c: 34 in setup_test() ________________________________________________________________________________________________________ *** CID 1446760: Resource leaks (RESOURCE_LEAK) /tests/lib/memset-test.c: 34 in setup_test() 28 29 return 0; 30 31 error: 32 free(buf); 33 free(helper_buf); >>> CID 1446760: Resource leaks (RESOURCE_LEAK) >>> Variable "s" going out of scope leaks the storage it points to. 34 return -1; 35 } 36 37 static int teardown_test(void **state) 38 { 39 struct memset_test_state *s = *state; ** CID 1446759: Security best practices violations (STRING_OVERFLOW) /src/mainboard/prodrive/hermes/mainboard.c: 99 in update_board_layout() ________________________________________________________________________________________________________ *** CID 1446759: Security best practices violations (STRING_OVERFLOW) /src/mainboard/prodrive/hermes/mainboard.c: 99 in update_board_layout() 93 if (cpu->bus->dev->path.type != DEVICE_PATH_CPU_CLUSTER) 94 continue; 95 if (!cpu->enabled) 96 continue; 97 layout.cpu_count++; 98 if (!layout.cpu_name[0]) >>> CID 1446759: Security best practices violations (STRING_OVERFLOW) >>> You might overrun the 50-character fixed-size string "layout.cpu_name" by copying "cpu->name" without checking the length. 99 strcpy(layout.cpu_name, cpu->name); 100 } 101 102 if (cpuid_get_max_func() >= 0x16) 103 layout.cpu_max_non_turbo_frequency = cpuid_eax(0x16); 104 ** CID 1446758: Memory - illegal accesses (NO_EFFECT) /tests/lib/memset-test.c: 88 in test_memset_zero_size() ________________________________________________________________________________________________________ *** CID 1446758: Memory - illegal accesses (NO_EFFECT) /tests/lib/memset-test.c: 88 in test_memset_zero_size() 82 for (int i = 0; i < MEMSET_BUFFER_SZ; ++i) { 83 s->base_buffer[i] = 0xFF; 84 s->helper_buffer[i] = 0xFF; 85 } 86 87 /* Expect no change in buffer after calling memset with zero size */ >>> CID 1446758: Memory - illegal accesses (NO_EFFECT) >>> Calling "memset" with size 0: "memset(s->base_buffer, 170, 0UL)" does nothing. 88 memset(s->base_buffer, 0xAA, 0); 89 assert_memory_equal(s->base_buffer, s->helper_buffer, MEMSET_BUFFER_SZ); 90 } 91 92 static void test_memset_one_byte(void **state) 93 { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

qemu and vboot: cannot locate verstage in CBFS
by Florian Laufenböck 17 Feb '21

17 Feb '21

Hi, I'm currently trying to enable vboot on qemu. I did the configuration and using the fmd file "vboot-rwa-16M.fmd" from subdir qemu-i440fx , but getting an error message like VBOOT: Loading verstage. Cannot locate primary CBFS I also tried to build the 4.13 release, but the result is the same with some other error message VBOOT: Loading verstage. failed to load verstage I already checked the changes and didn't saw anything which would explain may issue. May anybody have an idea (I think it's a configuration problem) how to make vboot and qemu working? I checked with cbfstool that the cbfs 'COREBOOT' is actually there, so IMHO it should at least detect the cbfs at least... Thanks a lot! Cheers, Florian

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 February 2021