coreboot August 2019

coreboot@coreboot.org

32 participants
23 discussions

Re: simplest fmap for minimal vboot deployment
by Persmule 19 Aug '19

19 Aug '19

And if so, NV storage seems not required any more under schemes without RW slot. Best regards, Persmule ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, August 19, 2019 7:57 AM, Persmule <persmule(a)hardenedlinux.org> wrote: > Thanks. Though I would rather push a change ( https://review.coreboot.org/c/coreboot/+/34977 ) to make vboot step into "recovery mode" directly when no RW slots is present, since I believe letting vboot "verify" a non-existing RW slot is mostly pointless. > > Is it convenient for me to bother you to review my change mentioned above? > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Sunday, August 18, 2019 4:43 PM, Michal Zygowski <michal.zygowski(a)3mdeb.com> wrote: > >> Yes, vboot requires NV storage to keep its context across boots, it is typically done in CMOS or SPI or EC memory. One of these 3 options must be selected. >> >> For example, in your mainboard Kconfig you should have something like this: >> >> config VBOOT >> bool >> default y >> select VBOOT_VBNV_CMOS >> select VBOOT_NO_BOARD_SUPPORT >> select GBB_FLAG_DISABLE_LID_SHUTDOWN >> select GBB_FLAG_DISABLE_PD_SOFTWARE_SYNC >> select GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC >> select GBB_FLAG_DISABLE_FWMP >> select RTC >> >> config VBOOT_VBNV_OFFSET >> hex >> default 0x2D8 if VBOOT >> >> The options you have to select highly depend on the hardware you are trying to run vboot on. For example vboot can start in bootblock or in romstage (depends on C_ENVIRONMENT_BOOTBLOCK support for the microarchitecture). The example shows sample configuration for CMOS stored vboot flags, however following options for vboot storage are also available (and have their own dependencies as well): >> - VBOOT_VBNV_EC >> - VBOOT_VBNV_FLASH >> >> I advise to look at src/security/vboot/Kconfig, help sections for the options might be helpful for you.

1 0

MIPS architecture support is rotting away... should we consider dropping it?
by Julius Werner 17 Aug '19

17 Aug '19

Hi, I've just been bitten by build problems with outdated MIPS code for one of my CLs (not for the first time), and I've been wondering if it's maybe time that we drop the architecture port completely. It was added 5 years ago to support a Chrome OS project that never ended up going anywhere and has been sitting in the tree unused and unsupported ever since. The only SoC/board building it is that old abandoned Chrome OS project for which there's probably not even any hardware around anymore (or if there is, nobody wants to spend time with it). There's no maintainer or even anybody who really reads MIPS assembly or understands the architecture's intricacies paying attention to it, and it keeps causing trouble when we try to pull it along with overarching refactorings. I think at some point, if nobody wants to use it and there's no future use case on the horizon, we should consider pulling the plug. Some examples of stuff that causes problems: 1. There's no 64-bit division support (even soft-division) because we have no code to implement the required libgcc function, and nobody knows enough MIPS assembly to fix that. We need to keep several hacks around in generic code (e.g. printf()) where code doesn't use 64-bit division even though it probably should or has a special #if CONFIG(ARCH_MIPS) case to deal with this. 2. The read/write8/16/32() functions in libpayload take arguments in (value, addr) order, whereas for all other architectures they have long since been standardized to take (addr, value). This means you can't submit any generic code that does direct MMIO without wrapping it in #if !CONFIG(ARCH_MIPS). There are a bunch of depthcharge drivers left still using that old convention... I don't have time/interest refactoring all of those and I don't think anybody else does either. We could either drop it right away, or (if we think that's too sudden) schedule it for deletion after the next coreboot release (4.11 in December(?)). What do people think?

5 6

Booting Legacy + UEFI disks: SeaBIOS / tianocore as secondary payload?
by Rafael Send 16 Aug '19

16 Aug '19

Hi, I'm trying to figure out how to build coreboot such that I can boot both legacy and UEFI systems. From what I can tell, most payloads will load either one or the other, but not both (unless Grub2 can do this - unclear to me). On the other hand, is it possible to use tianocore + SeaBIOS as the primary and secondary payloads, respectively? Or vice versa, I guess. If so, how would one go about setting that up? Menuconfig doesn't let me set arbitrary secondary payloads, so I'm guessing I'd have to stuff it in the CBFS manually somehow, yes? Cheers, Rafael

2 1

Re: G505s with minimal xorg + xfce4 + Mesa?
by Mike Banon 15 Aug '19

15 Aug '19

The proprietary graphics drivers for AMD GPUs found at G505S ( integrated HD-8650G and optional discrete HD-8570M or R5-M230 ) - are all deprecated, not supported by any modern (newer than Kubuntu 14.04.4) Linux distro. If you are using a modern Linux, you can't use the proprietary drivers for these cards even if you want - so, if these GPUs are working for you, you can be sure that they are working thanks to the opensource graphics drivers. I think they are called Mesa, although can be wrong. On Tue, Aug 13, 2019 at 8:55 PM <bruts(a)netc.fr> wrote: > > > Hi guys! > > Hope you having all a good summer period. I am testing some with my g505s laptops, now that I have a little time :-) > The proprietary graphics drivers for amd on linux are in the non-free repository, firmware-amd-graphics and firmware-linux-nonfree if i'm not mistaken < obviously we not want to use the binary files. > > What are the open-source alternatives? using Mesa? > > I try to create a very minimalist build of debian or alpine linux with minimal xorg+xfce < you guys must have done this before i am sure < how did you implement the gpu drivers? anything you can share with me? > > Thanks!

1 0

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

09 Aug '19

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 12 new defect(s) introduced to coreboot found with Coverity Scan. 9 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 12 of 12 defect(s) ** CID 1404005: Integer handling issues (SIGN_EXTENSION) /3rdparty/opensbi/lib/sbi/sbi_fifo.c: 79 in __sbi_fifo_reset() ________________________________________________________________________________________________________ *** CID 1404005: Integer handling issues (SIGN_EXTENSION) /3rdparty/opensbi/lib/sbi/sbi_fifo.c: 79 in __sbi_fifo_reset() 73 74 /* Note: must be called with fifo->qlock held */ 75 static inline void __sbi_fifo_reset(struct sbi_fifo *fifo) 76 { 77 fifo->avail = 0; 78 fifo->tail = 0; >>> CID 1404005: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "fifo->entry_size" with type "u16" (16 bits, unsigned) is promoted in "fifo->num_entries * fifo->entry_size" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "fifo->num_entries * fifo->entry_size" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 79 sbi_memset(fifo->queue, 0, fifo->num_entries * fifo->entry_size); 80 } 81 82 bool sbi_fifo_reset(struct sbi_fifo *fifo) 83 { 84 if (!fifo) ** CID 1404004: Control flow issues (NO_EFFECT) /3rdparty/opensbi/lib/utils/irqchip/plic.c: 57 in plic_fdt_fixup() ________________________________________________________________________________________________________ *** CID 1404004: Control flow issues (NO_EFFECT) /3rdparty/opensbi/lib/utils/irqchip/plic.c: 57 in plic_fdt_fixup() 51 { 52 u32 *cells; 53 int i, cells_count; 54 u32 plic_off; 55 56 plic_off = fdt_node_offset_by_compatible(fdt, 0, compat); >>> CID 1404004: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "plic_off < 0U". 57 if (plic_off < 0) 58 return; 59 60 cells = (u32 *)fdt_getprop(fdt, plic_off, 61 "interrupts-extended", &cells_count); 62 if (!cells) ** CID 1404003: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 1404003: Memory - corruptions (ARRAY_VS_SINGLETON) /3rdparty/opensbi/lib/sbi/riscv_atomic.c: 221 in atomic_clear_bit() 215 { 216 return atomic_raw_set_bit(nr, (unsigned long *)&atom->counter); 217 } 218 219 inline int atomic_clear_bit(int nr, atomic_t *atom) 220 { >>> CID 1404003: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "(unsigned long *)&atom->counter" to function "atomic_raw_clear_bit" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 221 return atomic_raw_clear_bit(nr, (unsigned long *)&atom->counter); ** CID 1404002: Integer handling issues (SIGN_EXTENSION) /3rdparty/opensbi/lib/sbi/sbi_fifo.c: 79 in __sbi_fifo_reset() ________________________________________________________________________________________________________ *** CID 1404002: Integer handling issues (SIGN_EXTENSION) /3rdparty/opensbi/lib/sbi/sbi_fifo.c: 79 in __sbi_fifo_reset() 73 74 /* Note: must be called with fifo->qlock held */ 75 static inline void __sbi_fifo_reset(struct sbi_fifo *fifo) 76 { 77 fifo->avail = 0; 78 fifo->tail = 0; >>> CID 1404002: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "fifo->num_entries" with type "u16" (16 bits, unsigned) is promoted in "fifo->num_entries * fifo->entry_size" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "fifo->num_entries * fifo->entry_size" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 79 sbi_memset(fifo->queue, 0, fifo->num_entries * fifo->entry_size); 80 } 81 82 bool sbi_fifo_reset(struct sbi_fifo *fifo) 83 { 84 if (!fifo) ** CID 1404001: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 1404001: Memory - corruptions (ARRAY_VS_SINGLETON) /3rdparty/opensbi/lib/sbi/riscv_atomic.c: 216 in atomic_set_bit() 210 { 211 return __atomic_op_bit(and, __NOT, nr, addr); 212 } 213 214 inline int atomic_set_bit(int nr, atomic_t *atom) 215 { >>> CID 1404001: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "(unsigned long *)&atom->counter" to function "atomic_raw_set_bit" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 216 return atomic_raw_set_bit(nr, (unsigned long *)&atom->counter); 217 } 218 219 inline int atomic_clear_bit(int nr, atomic_t *atom) 220 { 221 return atomic_raw_clear_bit(nr, (unsigned long *)&atom->counter); ** CID 1404000: Insecure data handling (TAINTED_SCALAR) /src/drivers/crb/tpm.c: 257 in tpm2_process_command() ________________________________________________________________________________________________________ *** CID 1404000: Insecure data handling (TAINTED_SCALAR) /src/drivers/crb/tpm.c: 257 in tpm2_process_command() 251 252 /* Response has to have at least 6 bytes */ 253 if (length < 6) 254 return 1; 255 256 // Copy Response >>> CID 1404000: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "length" to a tainted sink. [Note: The source code implementation of the function has been overridden by a builtin model.] 257 memcpy(tpm2_response, control_area.response_bfr, length); 258 259 if (crb_switch_to_ready()) { 260 printk(BIOS_DEBUG, "TPM: Can not transition into ready state again.\n"); 261 return -1; 262 } ** CID 1403999: Null pointer dereferences (FORWARD_NULL) /3rdparty/opensbi/lib/sbi/sbi_tlb.c: 74 in sbi_tlb_fifo_update_cb() ________________________________________________________________________________________________________ *** CID 1403999: Null pointer dereferences (FORWARD_NULL) /3rdparty/opensbi/lib/sbi/sbi_tlb.c: 74 in sbi_tlb_fifo_update_cb() 68 69 if (!in && !!data) 70 return ret; 71 72 curr = (struct sbi_tlb_info *)data; 73 next = (struct sbi_tlb_info *)in; >>> CID 1403999: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "next". 74 if (next->type == SBI_TLB_FLUSH_VMA_ASID && 75 curr->type == SBI_TLB_FLUSH_VMA_ASID) { 76 if (next->asid == curr->asid) 77 ret = __sbi_tlb_fifo_range_check(curr, next); 78 } else if (next->type == SBI_TLB_FLUSH_VMA && 79 curr->type == SBI_TLB_FLUSH_VMA) { ** CID 1403998: Integer handling issues (SIGN_EXTENSION) /3rdparty/opensbi/lib/sbi/sbi_fifo.c: 23 in sbi_fifo_init() ________________________________________________________________________________________________________ *** CID 1403998: Integer handling issues (SIGN_EXTENSION) /3rdparty/opensbi/lib/sbi/sbi_fifo.c: 23 in sbi_fifo_init() 17 { 18 fifo->queue = queue_mem; 19 fifo->num_entries = entries; 20 fifo->entry_size = entry_size; 21 SPIN_LOCK_INIT(&fifo->qlock); 22 fifo->avail = fifo->tail = 0; >>> CID 1403998: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "entry_size" with type "u16" (16 bits, unsigned) is promoted in "entries * entry_size" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "entries * entry_size" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 23 sbi_memset(fifo->queue, 0, entries * entry_size); 24 } 25 26 /* Note: must be called with fifo->qlock held */ 27 static inline bool __sbi_fifo_is_full(struct sbi_fifo *fifo) 28 { ** CID 1403997: Integer handling issues (SIGN_EXTENSION) /3rdparty/opensbi/lib/sbi/sbi_fifo.c: 23 in sbi_fifo_init() ________________________________________________________________________________________________________ *** CID 1403997: Integer handling issues (SIGN_EXTENSION) /3rdparty/opensbi/lib/sbi/sbi_fifo.c: 23 in sbi_fifo_init() 17 { 18 fifo->queue = queue_mem; 19 fifo->num_entries = entries; 20 fifo->entry_size = entry_size; 21 SPIN_LOCK_INIT(&fifo->qlock); 22 fifo->avail = fifo->tail = 0; >>> CID 1403997: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "entries" with type "u16" (16 bits, unsigned) is promoted in "entries * entry_size" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "entries * entry_size" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 23 sbi_memset(fifo->queue, 0, entries * entry_size); 24 } 25 26 /* Note: must be called with fifo->qlock held */ 27 static inline bool __sbi_fifo_is_full(struct sbi_fifo *fifo) 28 { ** CID 1403996: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/opensbi/lib/sbi/sbi_hart.c: 349 in sbi_hart_wait_for_coldboot() ________________________________________________________________________________________________________ *** CID 1403996: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /3rdparty/opensbi/lib/sbi/sbi_hart.c: 349 in sbi_hart_wait_for_coldboot() 343 wfi(); 344 mipval = csr_read(CSR_MIP); 345 346 spin_lock(&coldboot_wait_bitmap_lock); 347 coldboot_wait_bitmap &= ~(1UL << hartid); 348 spin_unlock(&coldboot_wait_bitmap_lock); >>> CID 1403996: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> The expression "mipval && 1 /* 1 << 3 */" is suspicious because it performs a Boolean operation on a constant other than 0 or 1. 349 } while (!(mipval && MIP_MSIP)); 350 351 csr_clear(CSR_MIP, MIP_MSIP); 352 } 353 354 void sbi_hart_wake_coldboot_harts(struct sbi_scratch *scratch, u32 hartid) ** CID 1403995: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 1403995: Memory - corruptions (ARRAY_VS_SINGLETON) /3rdparty/opensbi/lib/sbi/sbi_ipi.c: 122 in sbi_ipi_process() 116 sbi_tlb_fifo_process(scratch, ipi_event); 117 break; 118 case SBI_IPI_EVENT_HALT: 119 sbi_hart_hang(); 120 break; 121 }; >>> CID 1403995: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "&ipi_data->ipi_type" to function "atomic_raw_clear_bit" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 122 ipi_type = atomic_raw_clear_bit(ipi_event, &ipi_data->ipi_type); 123 } while (ipi_type > 0); 124 } 125 126 int sbi_ipi_init(struct sbi_scratch *scratch, bool cold_boot) 127 { ** CID 1403994: Memory - corruptions (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 1403994: Memory - corruptions (ARRAY_VS_SINGLETON) /3rdparty/opensbi/lib/sbi/sbi_ipi.c: 50 in sbi_ipi_send() 44 ret = sbi_tlb_fifo_update(remote_scratch, event, data); 45 if (ret > 0) 46 goto done; 47 else if (ret < 0) 48 return ret; 49 } >>> CID 1403994: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Passing "&ipi_data->ipi_type" to function "atomic_raw_set_bit" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 50 atomic_raw_set_bit(event, &ipi_data->ipi_type); 51 mb(); 52 sbi_platform_ipi_send(plat, hartid); 53 if (event != SBI_IPI_EVENT_SOFT) 54 sbi_platform_ipi_sync(plat, hartid); 55 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

simplest fmap for minimal vboot deployment
by Persmule 08 Aug '19

08 Aug '19

Hi all, I found the typical fmap for a coreboot build using vboot (e.g. those for chromeos) is quite complex, at least with two RW sections containing CBFS, but I only want to use vboot to perform TPM measurement (like what head does with a patched coreboot), so the simple scheme with a single CBFS containing all stages and payloads is prefered. My question is: if vboot is only used to perform TPM measurement, at least which sections must be added to the fmap, in addition to default ones (RW_MRC_CACHE and CBFS), allowing vboot to work?

2 5

Asrock E350M1/USB3 for free in Spain
by Alvaro G [Andor] 07 Aug '19

07 Aug '19

Hi there everybody! It's been a while! I'm 'decommissioning' an Asrock E350M1/USB I used with coreboot long time ago, but now it's been sitting idle around for years, and I want to donate it to somebody that might use it for something more usefuk tahn collecting dust. I know it's quite old, but you might do something useful with it. I think I can throw some memory with it, and some empty 64Mbit bios chips if I find them. If anybody wants it, just have to pay for shipping, or walk around Madrid and pick it :) Sorry for the OT. Regards. Andor

1 0

New on blogs.coreboot.org: [GSoC] Coreboot Coverity, weeks 8-10
by blogs.coreboot.org 07 Aug '19

07 Aug '19

1 0

flashrom: checking the order of flashchips.c
by Alan Green 06 Aug '19

06 Aug '19

Hi Nico, On the review of https://review.coreboot.org/c/flashrom/+/34488 you suggested adding a check for order of entries in flashchips.c. Sounds like a great idea, though I don't have much experience with Jenkins and I'd like to make sure I get this right. Did you have thoughts about how to implement it in a Jenkins-friendly way? Two approaches I was thinking about: (a) make a small C executable, that checks each entry is in order, and outputs a short message about any failures, along with a pass/fail exit code. (b) add that same functionality to the CLI, behind a flag. Do you have a preference for either of these, or some other approach? Alan

1 0

Abandoning ~250 coreboot patches older than 18 months
by Martin Roth 06 Aug '19

06 Aug '19

It's patch cleanup time again. This cleanup was last done almost 2 years ago, so there are a lot of old patches that haven't been touched in a while. Next week I'm going to abandon all of the open patches that haven't been touched in over 18 months. The list of roughly 250 patches to be abandoned is here: https://review.coreboot.org/q/status:open+before:2018-02-1+project:coreboot If anyone wants to take over any of these patches, just mention it in the patch and if the author doesn't respond in a day or two, feel free to let them know that you've adopted the patch. As always, if there's anything that is still useful and shouldn't be abandoned, a comment in the patch is enough to keep it alive in gerrit. Martin

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2019