Issue #426 has been updated by Martin Roth.
Status changed from New to Resolved
Fixed.
https://review.coreboot.org/c/coreboot/+/68752 - Documentation/measured_boot.md: document new TPM options
https://review.coreboot.org/c/coreboot/+/68751 - Documentation/measured_boot.md: fix SRTM/DRTM explanations
----------------------------------------
Documentation #426: Document existing and added TPM event log formats and PCR usage
https://ticket.coreboot.org/issues/426#change-1703
* Author: Krystian Hebel
* Status: Resolved
* Priority: Normal
* Category: Documentation
* Target version: none
* Start date: 2022-10-12
----------------------------------------
Documentation should mention at least:
- what formats are available and where they are described
- what are possible consumers of each format
- which hashing algorithms can be used
- what additional info is added to that required by specification, if any
- which component is extended to which PCR for each of supported scheme (may be in form of example event log)
Additionally, existing vboot documentation should be fixed, especially parts describing SRTM and DRTM.
--
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
Issue #425 has been updated by Martin Roth.
Status changed from New to Resolved
Fixed: https://review.coreboot.org/c/coreboot/+/68749 - util/cbmem: add parsing of TPM logs per specs
----------------------------------------
Feature #425: Add parsing of new TPM event log formats to cbmem utility
https://ticket.coreboot.org/issues/425#change-1702
* Author: Krystian Hebel
* Status: Resolved
* Priority: Normal
* Category: userspace utilities
* Target version: none
* Start date: 2022-10-12
* Related links: https://review.coreboot.org/c/coreboot/+/51583
----------------------------------------
All existing and newly implemented formats must be parse-able by cbmem. It should be able to automatically recognize used format and parse it accordingly, so there are no significant differences in invocation of this tool by end users. Crypto agile format will require implementation of additional unmarshaling.
--
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
Issue #431 has been updated by Martin Roth.
Status changed from New to Closed
These issues are not harmful and have been marked as intentional in coverity.
----------------------------------------
Bug #431: fix src/arch/x86/smbios issues
https://ticket.coreboot.org/issues/431#change-1701
* Author: Martin Roth
* Status: Closed
* Priority: Normal
* Assignee: Solomon Alan-Dei
* Category: coreboot common code
* Target version: none
* Start date: 2022-10-20
----------------------------------------
There are currently 20 coverity issues affecting smbios code in src/arch/x86/smbios*
https://scan6.scan.coverity.com/reports.htm#v55284/p10744https://docs.google.com/spreadsheets/d/1hacitQU1zn7CU44eXP3xVdvq-OjnIF_h8LR…
---Files--------------------------------
Outstanding+Issues+in+smbios.csv (3.61 KB)
--
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
Issue #444 has been updated by Martin Roth.
These tests are disabled and will be deleted unless fixed.
----------------------------------------
Bug #444: Flaky gitconfig tests are breaking builds
https://ticket.coreboot.org/issues/444#change-1700
* Author: Martin Roth
* Status: New
* Priority: Normal
* Category: build system
* Target version: none
* Start date: 2022-12-20
----------------------------------------
The gitconfig tests are failing when they can't delete a directory they created in /tmp, and this is causing builds to fail randomly.
Because it's not a part of the test itself, but part of the cleanup, the failure doesn't get captured, and jenkins appears to be failing for no good reason.
Someone should figure out what's causing the rm -rf to fail and fix it so that the builders stop failing.
--
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
Issue #444 has been updated by Martin Roth.
Category set to build system
----------------------------------------
Bug #444: Flaky gitconfig tests are breaking builds
https://ticket.coreboot.org/issues/444#change-1699
* Author: Martin Roth
* Status: New
* Priority: Normal
* Category: build system
* Target version: none
* Start date: 2022-12-20
----------------------------------------
The gitconfig tests are failing when they can't delete a directory they created in /tmp, and this is causing builds to fail randomly.
Because it's not a part of the test itself, but part of the cleanup, the failure doesn't get captured, and jenkins appears to be failing for no good reason.
Someone should figure out what's causing the rm -rf to fail and fix it so that the builders stop failing.
--
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
Issue #475 has been reported by Bill XIE.
----------------------------------------
Bug #475: mainboard_vbt_filename() in src/mainboard/lenovo/x200/blc.c does not work as intended
https://ticket.coreboot.org/issues/475
* Author: Bill XIE
* Status: New
* Priority: Normal
* Assignee: Arthur Heymans
* Category: board support
* Target version: master
* Start date: 2023-03-30
* Affected versions: 4.15, 4.16, 4.17, 4.18, 4.19, master
* Affected hardware: x200
----------------------------------------
Date back to coreboot 4.9, mainboard_vbt_filename() in src/mainboard/lenovo/x200/blc.c calls get_blc_pwm_freq_value(NULL), making the following if condition always falling to the first, not to mention null dereference on strcmp() in get_blc_pwm_freq_value().
In order to determine the correct vbt filename at runtime, edid ascii string should be obtained first.
This issue may be distantly related to #474.
--
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
Issue #485 has been reported by Rajat Dongre.
----------------------------------------
Support #485: Request for Support for Intel Xeon 1700 D Processor Family in Coreboot(Ice Lake)
https://ticket.coreboot.org/issues/485
* Author: Rajat Dongre
* Status: New
* Priority: Immediate
* Assignee: Rajat Dongre
* Target version: none
* Start date: 2023-04-27
----------------------------------------
Hi,
I am writing this email to request support for the Intel Xeon 1700 D processor family (Ice Lake) in Coreboot. As you may be aware, the support for the IceLake SOC has been removed, and I am using a processor from the same family.
I would appreciate any help or guidance on how to bring up my processor using Coreboot. I have been using Coreboot for some time and am familiar with its functionalities, but I am facing difficulties with the processor mentioned above. and Can I used to older version of coreboot where you give support for the Ice lake but the Intel Xeon 1700 D processor family launch in Dec 2022. so I have doubt I will work for this SOC as the Icelake is not updated from last 4 years in coreboot.
I would be grateful if you could provide any relevant documentation, code, or instructions to help me with my request. I believe that my request will not only benefit me but also other members of the community who are facing similar challenges.
Thank you for your time and consideration, and I look forward to hearing from you soon.
--
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
Issue #479 has been reported by Jonas Termansen.
----------------------------------------
Other #479: [legal] ISC License copyright violation in ubsan
https://ticket.coreboot.org/issues/479
* Author: Jonas Termansen
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-04-09
----------------------------------------
Hi :)
coreboot has removed my copyright statement from the ubsan implementation, which violates my copyright as licensed to you under the terms of the ISC License:
```
* Copyright (c) 2014, 2015 Jonas 'Sortie' Termansen.
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* ...
```
The file in question is: https://github.com/coreboot/coreboot/blob/master/src/lib/ubsan.c
The file does clearly state it's forked from my original ubsan implementation: https://gitlab.com/sortix/sortix/-/blob/master/libc/ubsan/ubsan.c
However, the coreboot copy has removed my copyright notice, which is one of only two terms of the license. It's fine that the permission notice has been changed to `SPDX-License-Identifier: ISC` which is unambiguously information preserving, but removing my copyright notice is a loss of information.
The copyright notice was removed in https://github.com/coreboot/coreboot/commit/16849bbe0c8a79277e1a682dcb42eaf… which moved my name to AUTHORS. Although a mention in AUTHORS is appreciated, it removes the association between the file's contents and my identity and my moral rights to my work. Although the full information is available in the git history, that's not good enough. I'm concerned that further copies of the file in other projects may lose the authorship information entirely.
Please restore my copyright notice at the top of the file :)
Jonas 'Sortie' Termansen
--
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
Issue #500 has been reported by Thierry Laurion.
----------------------------------------
Bug #500: libgfxinit bootsplash only supports jpeg and does not support extended resolutions
https://ticket.coreboot.org/issues/500
* Author: Thierry Laurion
* Status: New
* Priority: Normal
* Assignee: Patrick Georgi
* Category: coreboot common code
* Target version: master
* Start date: 2023-07-13
* Related links: https://github.com/coreboot/coreboot/blob/master/src/lib/jpeg.chttps://git.seabios.org/seabios.git/https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad…
WiP PoC: https://github.com/osresearch/heads/pull/1403
* Affected hardware: iGPU driven by libgfxinit
* Affected OS: All
----------------------------------------
For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAt…
Short version:
- libgfxinit bootsplash through jpeg.c supports VESA old resolutions (1024x768)
- libgfxinit bootsplash through jpeg.c doesn't support native resolutions (1366x768)
- libgfxinit bootsplash image creation requires voodoo skills explained at https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017
- Basically, I do not think libgfxinit bootsplash is currently used otherwise there would be way more bug reports. Seabios is mostly used.
- Seabios bootsplash code should be borrowed (lgplv3) which supports both BMP and JPEG and is not 13yo.
- Coreboot should permit stiching of compressed bmp by default and deprecate old jpeg.c in tree
- By doing so, more people could promote coreboot directly from coreboot raminit (Heads currently does that)
Longer version:
- OSes are attacking legacy BIOS mode for a while now, and the next steps are to deprecate DRM drivers in initrd
- To phase DRM out, simplefb and simpledrm are promoted instead where final OS will be in charge of deploying bigger unified kernels containing/initrd which will contain the accelerated DRM and fb drivers
- Currently deploying DRM drivers inside of linuxboot (heads) on Intel iGPU requires to include i915drmfb, coreboot linux command lines hacks to have the FB address exposed (tainting the kernel) and kexec hacked to expose exposed fb address to next kernel (see https://github.com/osresearch/heads/pull/1378)
- Doing currently adds more then 500kb of in-kernel drivers, which bloats the firmware. In case of measured boot, that bigger payload needs to be measured prior of being read and jumped into (8-10 seconds under 5.10 kernel compared to 4-6 seconds under 4.14)
- To have legacy BIOS survive this ecosystem attack against legacy boot, coreboot needs to push for a more generic way to provide a framebuffer (GOP/Native unified approach)
- With libgfxinit/GOP/native gfx init and the kernel config adapted, linux can efficiently be used as a bootloader and be enabled by simplefb (https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad…)
- The part missing is having coreboot drive the framebuffer with a native size bootsplash as everyone else does so that the waiting time to boot in kernel/payload is not a scary moment, and that the bootsplash doesn't restrict the size of the framebuffer configured under coreboot nor limit the UX.
Actual state:
- libgfxinit needs to have jpeg supported resolution to bootsplash (CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768 CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024)
- libgfxinit bootsplash needs to have a 1024x768 voodoo crafted jpeg (https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-…)
- Problem is that doing so, the whole console is limited to that resolution showing black borders on each side of the screen to compensate (1366 != 1024, so (1366-1024)/2 is the loss pixel width on each side of the screen for 1366x764, same applying to all other resolutions since needs to be 4x4 for jpeg.c to do its job.
Desired state:
- flat bmp support in native format just like seabios support, where coreboot compressed them prior of adding it into CBFS.
- support for all crazy resolutions we currently have, not being stuck in 2000.
- Be able to promote coreboot from raminit code.
---Files--------------------------------
signal-2023-07-13-164022.jpeg (269 KB)
signal-2023-07-13-164047.jpeg (416 KB)
VID_20230713_154446.mp4 (3.78 MB)
--
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
Issue #511 has been reported by Elias Souza.
----------------------------------------
Bug #511: [STM/PE][BUG][SMMSTORE] Coreboot doesn't boot if SMMSTOREv2 driver Kconfig option is enabled
https://ticket.coreboot.org/issues/511
* Author: Elias Souza
* Status: Needs Testing
* Priority: High
* Category: coreboot common code
* Target version: 4.21
* Start date: 2023-10-09
* Affected hardware: is necessary testing in newest hardwares include Haswell and Kaby Lake, but idk if affect other platforms different than Sandybridge
* Affected OS: All
----------------------------------------
For some reason the SMMSTOREv2 looks to break SMMSTORE support in STM/PE during boot.
Coreboot: 4.21
HARDWARE: Gigabyte H61M-DS2 with Ivybridge processor
Payload: EDK2
SMMSTORE: SMMSTOREv2
A example with other guy using https://www.reddit.com/r/coreboot/comments/10rakni/comment/k444jz1/?context…
* According with the reddit user crazyfox-ua " The same for me on T440p & X230t (both with edk2) - just blank screen. Disabled STM brings both laptops back to life. CB logs says nothing strange IMO (last record is "[DEBUG] Jumping to boot code at <hex here>".
Is necessary to test if others payloads is affected by this bug
--
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