coreboot June 2017

coreboot@coreboot.org

57 participants
159 discussions

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

27 Jun '17

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 1376664: Null pointer dereferences (REVERSE_INULL) /src/soc/amd/stoneyridge/northbridge.c: 666 in cpu_bus_scan() ________________________________________________________________________________________________________ *** CID 1376664: Null pointer dereferences (REVERSE_INULL) /src/soc/amd/stoneyridge/northbridge.c: 666 in cpu_bus_scan() 660 * this silicon. It is an SOC and can't have >= 16 APICs, but 661 * we will start numbering at 0x10. We also know there is only 662 * on physical node (module in AMD speak). 663 */ 664 665 lapicid_start = 0x10; /* Get this from devicetree? see comment above. */ >>> CID 1376664: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "cdb_dev" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 666 enable_node = cdb_dev && cdb_dev->enabled; 667 cpu_bus = dev->link_list; 668 669 for (j = 0; j <= siblings; j++ ) { 670 apic_id = lapicid_start + j; 671 printk(BIOS_SPEW, "lapicid_start 0x%x, node 0x%x, core 0x%x, apicid=0x%x\n", ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] GPG public key for corboot release signatures
by Alexander Couzens 27 Jun '17

27 Jun '17

Hi Laszlo, you can find the keys on the public key servern. I've attached the fingerprints, but gpg can also show you when trying to verify it. > Why are there two signatures in the GPG signature file (for release > 4.6) and why do the signature dates differ from the release date > (according to the website)? More signatures are better ;). Choose your own trust anchor. I've signed it after it was released. Best, lynxis Alexander Couzens <lynxis(a)fe80.eu> Key fingerprint = 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604 Martin Roth (coreboot developer) <martin(a)coreboot.org> Key fingerprint = 574C E6F6 855C FDEB 7D36 8E9D 1979 6C2B 3E4F 7DF7 -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

2 1

Re: [coreboot] Unable to include iPXE in coreboot
by Idwer Vollering 26 Jun '17

26 Jun '17

It's installed through the liblzma-dev package: https://packages.debian.org/stretch/amd64/liblzma-dev/filelist 2017-06-26 15:13 GMT+02:00 Dhanasekar Jaganathan <jdhanasekarmca(a)gmail.com>: > Hi All, > > I am trying to enable ethernet in coreboot + GRUB2. So I have enabled > following option in make meuconfig, > > 1. Payload -> Add a PXE ROM = Y > 2. Payload -> PXE options -> PXE ROM to use = "Build and add an iPXE ROM . > > After enabling those option, I am getting below error, > > "util/zbin.c:7:18: fatal error: lzma.h: No such file or directory." > > I have noticed lzma.h is not available in /payloads/external/iPXE/ipxe/src. > > Is there any option I have to enable? or have I missed any option ? in make > menuconfig. > > Correct me, If steps (which I followed) to enable PXE ROM is wrong. > > > Thanks, > Dhanasekar > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Unable to include iPXE in coreboot
by Dhanasekar Jaganathan 26 Jun '17

26 Jun '17

Hi All, I am trying to enable ethernet in coreboot + GRUB2. So I have enabled following option in make meuconfig, *1. Payload -> Add a PXE ROM = Y* *2. Payload -> PXE options -> PXE ROM to use = "Build and add an iPXE ROM .* After enabling those option, I am getting below error, *"util/zbin.c:7:18: fatal error: lzma.h: No such file or directory."* I have noticed lzma.h is not available in /payloads/external/iPXE/ipxe/src. Is there any option I have to enable? or have I missed any option ? in make menuconfig. Correct me, If steps (which I followed) to enable PXE ROM is wrong. Thanks, Dhanasekar

1 0

AMD Lenovo G505S = ok ! Please share your reports for other boards, especially Unknown status
by Ivan Ivanov 25 Jun '17

25 Jun '17

Dear friends, as I see by this mailing list: there are enough people using AMD Lenovo G505S notebook but nobody has submitted a report since october 2016... I just rebuilt coreboot, tested and it boots ok - here is my new full report : https://review.coreboot.org/cgit/board-status.git/log/lenovo/g505s But there are a lot of boards which have been without new reports for a long time, or even without any reports at all! (status "Unknown") :P If you have any of such boards, please submit a report: it may be very helpful to other people, especially coreboot beginners who are making their first purchase decision about the coreboot hardware. Instruction how to produce and share your reports - could be seen at the beginning of "Supported Motherboards" page: https://www.coreboot.org/Supported_Motherboards For the successful execution of ./util/board_status/board_status.sh script make sure that your utils such as cbmem and cbfstool - have been successfully compiled. If you still have some trouble: open that board_status.sh script, check how it works and maybe make some edits or extract the commands to execute them separately (while keeping in mind the environmental variables) After you successfully submit, your report will be added to board_status repository and should be visible at Supported_Motherboards page, just wait until the 2nd minute of next hour then refresh a page. And maybe there will be new coreboot users with this board, thanks to your activities Best regards, Ivan Ivanov

1 0

Re: [coreboot] FILO 0.6.0 payload bootloader - Bug Reports!
by Nico Huber 24 Jun '17

24 Jun '17

Hello Ivan, On 13.06.2017 23:51, Ivan Ivanov wrote: > Sadly "filo> kernel hda1:/vmlinuz" doesnt work as well: gives > Disk read error dev=1 drive=0 sector=0 this sounds much like the drive wasn't detected at all, not 100% sure though. If you enabled the libpayload AHCI driver, it should show detected drives on the console (only a short moment if you enabled the GRUB interface). A serial log would help or if that's not pos- sible, you can disable the GRUB interface to see the output, IIRC. > > Error 15: File not found > > My current situation seems like a standard use case: > 1) ext2 boot partition at /dev/sda1 (or which is called "hda1" in this case), > size of which is 1GB and it is at DOS-partitioned MBR hard drive It could also be the size of the filesystem. IIRC, I've run into pro- blems with bigger partitions too, but ignored them because our OS uses small boot partitions. You could try the same partitioning and file system in QEMU. > 2) vmlinuz is at hda1:/vmlinuz , initrd is at hda1:/initrd > > But so far I am unable to even load a kernel. > Either I am doing something very wrong or there is a fundamental > problem with FILO which makes it useless outside of QEMU and maybe a > couple of IDE legacy systems.... which is really sad if indeed the > case :P > > By the way, when I run "probe" command it tells: > IDE channel 0 not found > IDE channel 0 not found > IDE channel 1 not found > IDE channel 1 not found > IDE channel 2 not found > IDE channel 2 not found > IDE channel 3 not found > IDE channel 3 not found > > No word about SATA, but maybe this is a correct behaviour? or not? It is expected behaviour. We've integrated the libpayload storage driver with little love, it just works for the file-system backend. Nico

2 1

EDID versus VBT, and their cooperation/relationship?!
by Zoran Stojsavljevic 24 Jun '17

24 Jun '17

Hello Coreboot folks, I am opening the another thread, trying better to understand GFX Coreboot architecture, as well as Linux GFX one. And relationships between these two. Here are some rules I'll assume they are correct (my best guess), after I started investigating this area. - While BSP/Coreboot (EDID not read from the actual monitor yet), the only entity which applies for attached monitor for timings is VBT.dat (if applied in Coreboot, assuming it does). - VBT.dat is passed via vBIOS or GOP (dynamically) to Linux kernel while it boots. How and in which phase it is done, I have very little understanding. More I do understand if vBIOS (CSM ON) is passed to kernel (as part of Option ROM), but not really clear to me where vbt.dat (where exactly ?) will finish after Coreboot is done. - No matter what and how vbt.dat is passed and where, monitor's EDID will be read using DDC/CI protocol, while initializing kernel GFX, to obtain all the true/natural timing data for the present monitor (if implemented/applicable). And here are the questions, regarding what I wrote here: [1] Where in the kernel structures VBT.dat will be kept/held (it'll be added on fly after BSP is done, somewhere in the allocated heap - the APIs describing it will be somewhere here: drivers/gpu/drm/i915/)? [2] In other words, VBT.dat will be the part of DRM (i915 GFX driver), part of kernel space, correct? [3] What about EDID, if it is/was successfully read? It obviously has precedence over VBT.dat, correct? [4] Does DRI API (DRILib, DRI -> Direct Rendering Infrastructure) as part of X11 server, provide the only access to VBT.dat? [5] Does DRI API (DRILib) as part of X11 server, provide the only access to EDID, previously read from attached monitor (via DDC/CI protocol)? [6] Alternative to [4], does DRM API (part of kernel space, top layer, above i915 driver) provide the only access to VBT.dat? [7] Alternative to [5], does DRM API provide the only access to EDID? [8] Please, if you like, add your own understanding of this architecture. [9] Whatever you have to add, subtract, change... You name it! I really would like to open this thread in order to clear lot of fog, created by Linux maintainers, INTEL, and Linux GFX designers, as main reason driving this email to get much better Linux/kernel GFX picture/architecture understanding??? Thank you all in advance! Zoran Stojsavljevic

1 0

[TOOLS] G505S owners - Extract all Option ROMs now! InsydeH20 BIOS dev tools release
by Mike Banon 23 Jun '17

23 Jun '17

Insyde Software Japan has released some of their outdated BIOS dev tools: GitHub repository - https://github.com/s-sosnitskiy80/Insider_BIOS_Tools https://www.bios-mods.com/forum/Thread-Insider-BIOS-Tools-First-Release Already downloaded them and tested! Perhaps the only one of InsydeH20 tools that can be (very!) useful to us,the glorious coreboot people, - is H20EZE : "H20EZE: Easy BIOS Editor that helps edit binaries in the BIOS, including Option ROMs, driver binaries, logos, and Setup values" I have G505S coreboot-supported AMD laptop which originally had InsydeH20 proprietary BIOS. Until this day it has been possible to extract only a few option ROMs from this BIOS; e.g. to extract VGABIOS of A10-5750M integrated graphics by the "Retrieval via Linux kernel" method - which gives you a ROM that has been significantly altered during the proprietary BIOS boot time. Other ROMs, such as discrete graphics ROM, were impossible to extract at all (some modifications of G505S laptop - have HD 8570M or R5 M230 discrete GPU) Using this H20EZE tool I have successfully extracted all 15 Option ROMs in their pristine state! Not modified by the proprietary BIOS while booting :) * 8 VGABIOS ROMs (3 of which could be suitable for various G505S versions: ROMs for HD 8650G integrated graphics and for HD 8570M and R5 M230 discrete) * 6 Intel Boot Agent PXE ROMs(aka backdoors;) - 4 for Atheros, 2 for Realtek * 1 AHCI ROM for AMD SATA controller of SB7x0/SB8x0/SB9x0 southbridge Currently I am extracting all 284 proprietary UEFI/BIOS modules, because some of them could be very useful for reverse engineering the software-only internal method/protocol of flashing the KB9012 EC controller 128KB firmware G505S firmware inside KB9012 EC keyboard controller - is closed source and must be reverse engineered. Its much faster to develop a free-as-in-freedom firmware replacement if you could reflash a firmware internally: it takes less than a minute, while the currently-available-to-us hardware flashing method (via flashrom with a keyboard flex cable) takes at least 15 minutes! Also it will be easier to internally flash a reverse engineered firmware Sadly it is impossible to extract multiple modules or OpROMs in one single action; you have to extract them one-by-one, so it is going to take me a few hours to correctly extract all 284 modules without any mistakes and repeats Currently this H20EZE tool is closed source and Windows only (it seems that Linux version has not been released yet), and for these reasons, despite these tools have been re-licensed to a permissive freeware CC-ND license, they should not be included to our bios_extract repository available here: https://review.coreboot.org/cgit/bios_extract.git/tree/ By the way this coreboot's repository has some unofficial "insyde-tools", but frankly they are total garbage: cannot extract anything from my BIOS! The official H20EZE tool is performing much much better - and although it is 3 years old, the latest proprietary BIOS for G505S is even older, so its OK Best regards, Mike Banon

1 0

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

23 Jun '17

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. 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 3 of 3 defect(s) ** CID 1376473: Code maintainability issues (UNUSED_VALUE) /src/soc/intel/quark/spi.c: 169 in xfer() ________________________________________________________________________________________________________ *** CID 1376473: Code maintainability issues (UNUSED_VALUE) /src/soc/intel/quark/spi.c: 169 in xfer() 163 } 164 165 /* Use chip select 0 */ 166 ctrlr->address = (data[0] << 16) 167 | (data[1] << 8) 168 | data[2]; >>> CID 1376473: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "ctrlr->address" to "status" here, but that stored value is overwritten before it can be used. 169 status = ctrlr->address; 170 data += 3; 171 bytesout -= 3; 172 } 173 174 /* Build the control value */ ** CID 1376472: Integer handling issues (SIGN_EXTENSION) /src/commonlib/storage/mmc.c: 436 in mmc_update_capacity() ________________________________________________________________________________________________________ *** CID 1376472: Integer handling issues (SIGN_EXTENSION) /src/commonlib/storage/mmc.c: 436 in mmc_update_capacity() 430 /* Determine the user partition size 431 * 432 * According to the JEDEC Standard, the value of 433 * ext_csd's capacity is valid if the value is 434 * more than 2GB 435 */ >>> CID 1376472: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "ext_csd[215]" with type "unsigned char" (8 bits, unsigned) is promoted in "(ext_csd[212] << 0) | (ext_csd[213] << 8) | (ext_csd[214] << 16) | (ext_csd[215] << 24)" to type "int" (32 bits, signed), then sign-extended to type "unsigned long long" (64 bits, unsigned). If "(ext_csd[212] << 0) | (ext_csd[213] << 8) | (ext_csd[214] << 16) | (ext_csd[215] << 24)" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 436 capacity = (ext_csd[EXT_CSD_SEC_CNT + 0] << 0 | 437 ext_csd[EXT_CSD_SEC_CNT + 1] << 8 | 438 ext_csd[EXT_CSD_SEC_CNT + 2] << 16 | 439 ext_csd[EXT_CSD_SEC_CNT + 3] << 24); 440 capacity *= 512; 441 if ((capacity >> 20) > 2 * 1024) ** CID 1325831: Insecure data handling (TAINTED_SCALAR) /src/lib/tlcl.c: 242 in tlcl_read() ________________________________________________________________________________________________________ *** CID 1325831: Insecure data handling (TAINTED_SCALAR) /src/lib/tlcl.c: 242 in tlcl_read() 236 237 result = tlcl_send_receive(cmd.buffer, response, sizeof(response)); 238 if (result == TPM_SUCCESS && length > 0) { 239 uint8_t *nv_read_cursor = response + kTpmResponseHeaderLength; 240 from_tpm_uint32(nv_read_cursor, &result_length); 241 nv_read_cursor += sizeof(uint32_t); >>> CID 1325831: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "result_length" to a tainted sink. [Note: The source code implementation of the function has been overridden by a builtin model.] 242 memcpy(data, nv_read_cursor, result_length); 243 } 244 245 return result; 246 } 247 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

GPG public key for corboot release signatures
by László Szücs 23 Jun '17

23 Jun '17

Hi all! I have a potentially silly question: I would like to use the coreboot 4.6 release from the coreboot.org website. To be sure i would like to verify the GPG signature. Where can I find the appropriate public key(s) for the verification? Why are there two signatures in the GPG signature file (for release 4.6) and why do the signature dates differ from the release date (according to the website)? Thanks and apologies if I overlooked/misinterpreted something, László

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 June 2017