coreboot

coreboot@coreboot.org

6 participants
39686 discussions

Add openpgp smartcard authentication
by t＠okpl.ru 21 Nov '23

21 Nov '23

2 1

[coreboot - Support #515] (New) CONFIG_DRIVERS_PS2_KEYBOARD=y doesn't fixate detected keyboard to AT Translated 2 between cold/warm boot
by Thierry Laurion 20 Nov '23

20 Nov '23

Issue #515 has been reported by Thierry Laurion. ---------------------------------------- Support #515: CONFIG_DRIVERS_PS2_KEYBOARD=y doesn't fixate detected keyboard to AT Translated 2 between cold/warm boot https://ticket.coreboot.org/issues/515 * Author: Thierry Laurion * Status: New * Priority: Normal * Target version: none * Start date: 2023-11-20 * Affected versions: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master ---------------------------------------- This is a long term issue under QubesOS for x230t/x220t and now x230 users as an be seen https://github.com/QubesOS/qubes-issues/issues/3306 The reason is unclear since it is not a generalized behavior. Is it because of EC firmware version variation, keyboard SKU? User reports don't clarify this enough. What is known (Heads linux payload of coreboot here). If coreboot doesn't do anything for ps2 keyboard, linux does what it can to initialize ps2 and then determine mode of comms, which varies across cold boot/warm boot and sometimes falls back to Raw 2 Translated, which OSes behavior for keyboard cause issues with Backspace, | and \ keys. This is short version of https://github.com/QubesOS/qubes-issues/issues/3306 ---- cbmem -1 filtered output: Coldboot with/without CONFIG_DRIVERS_PS2_KEYBOARD=y ![not normal](https://github.com/linuxboot/heads/assets/827570/c05f82e7-da27-4056… Warm boot: ![normal](https://github.com/linuxboot/heads/assets/827570/5b4009a9-28ea-4c63-98f4-17a472f3b3a2) ---- When applying ugly hack on pc80 coreboot driver: - discussion https://github.com/QubesOS/qubes-issues/issues/3306#issuecomment-1817347378) - ugly patch https://github.com/linuxboot/heads/pull/1525/commits/1a6fbfa26ebf0a0afb58a9… coldboot issue resolved by removing exit 0 from patch above: ![signal-2023-11-18-05-49-02-251-1.jpg](https://github.com/QubesOS/qubes-issues/assets/827570/fe2e509f-8838-41f4-a8b4-bb92ba546c27) So it seems that we could force AT Translated 2 for keyboards that need it. Linux i8042.debug output given by user under https://github.com/linuxboot/heads/pull/1525 (i8042.notimeout, i8042.debug andcoreboot CONFIG_DRIVERS_PS2_KEYBOARD=y on): - [i8042 debug output being going into AT 2 Translated mode](https://github.com/linuxboot/heads/files/13352680/dom0_dmesg_i8042_su… - [i8042 debug output being going into Raw 2 Translated mode](https://github.com/linuxboot/heads/files/13352681/dom0_dmesg_i8042_fa… --- Other solutions attempted: - Forcing coreboot-> linux i8042 options through COMMAND_LINE without success: i8042.translate=1:kbd, i8042.reset + i8042.notimeout and others without success. Coldboot still shows Raw Translated 2 Other possibilities suggested by chat: - adapt pc80 or borrow fixes from libpayload/unifying pc80 code. -- 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

1 1

RFCv3: Post-build control of serial console
by Simon Glass 20 Nov '23

20 Nov '23

Hi, I sent an updated CL for this here: https://review.coreboot.org/c/coreboot/+/77712 There are a few questions to resolve. As an example, here is the bootblock output on brya that can be controlled with this RFC. [NOTE ] coreboot-coreboot-unknown.9999.915d387 Wed Nov 15 17:48:38 UTC 2023 x86_32 bootblock starting (log level: 8)... [DEBUG] CPU: 12th Gen Intel(R) Core(TM) i3-1215U[DEBUG] CPU: ID 906a4, Alderlake R0 Platform, ucode: 00000430 [DEBUG] CPU: AES supported, TXT NOT supported, VT supported[INFO ] Cache: Level 3: Associativity = 10 Partitions = 1 Line Size = 64 Sets = 16384 [INFO ] Cache size = 10 MiB[DEBUG] MCH: device id 4609 (rev 04) is Alderlake-P [DEBUG] PCH: device id 5182 (rev 01) is Alderlake-P SKU[DEBUG] IGD: device id 46b3 (rev 0c) is Alderlake P GT2 [INFO ] VBNV: CMOS invalid, restoring from flash[DEBUG] FMAP: Found "FLASH" version 1.1 at 0x1804000. [DEBUG] FMAP: base = 0x0 size = 0x2000000 #areas = 35[DEBUG] FMAP: area RW_NVRAM found @ f2b000 (24576 bytes) [INFO ] SF: Detected 00 0000 with sector size 0x1000, total 0x2000000 [INFO ] VBNV: Restore from flash failed [INFO ] Probing TPM I2C: I2C bus 1 version 0x3230302a [INFO ] DW I2C bus 1 at 0xfe022000 (400 KHz) [ERROR] I2C TX abort detected (00000001) [ERROR] cr50_i2c_read: Address write failed [INFO ] .done! DID_VID 0x00281ae0 [INFO ] TPM ready after 0 ms [DEBUG] cr50 TPM 2.0 (i2c 1:0x50 id 0x28) [INFO ] Firmware version: B2-C:0 RO_B:0.0.12/9eb618de RW_A:0.6.201/cr50_v3.9 [ERROR] Current CR50_BOARD_CFG = 0x80000001, does not matchdesired = 0x00000000 [INFO ] tlcl_send_startup: Startup return code is 0x0 [INFO ] TPM: setup succeeded [INFO ] src/security/tpm/tss/tcg-2.0/tss.c:253 index 0x1007 return code 0x0 [INFO ] src/security/tpm/tss/tcg-2.0/tss.c:253 index 0x1008 return code 0x0 [DEBUG] Chrome EC: UHEPI supported [DEBUG] Reading cr50 boot mode [INFO ] GSC says boot_mode is VERIFIED_RW(0x00). [INFO ] Phase 1 [DEBUG] FMAP: area GBB found @ 1805000 (458752 bytes) [INFO ] VB2:vb2_check_recovery() Recovery reason from previous boot: 0x0 / 0x0 [INFO ] Phase 2 [INFO ] Phase 3 [DEBUG] FMAP: area GBB found @ 1805000 (458752 bytes) [DEBUG] FMAP: area VBLOCK_A found @ 500000 (65536 bytes) [DEBUG] FMAP: area VBLOCK_A found @ 500000 (65536 bytes) [INFO ] VB2:vb2_verify_keyblock() Checking keyblock signature... [INFO ] VB2:vb2_digest_init() 1144 bytes, hash algo 3, HW acceleration unsupported [INFO ] VB2:vb2_verify_digest() HW RSA for sig_alg 5 not supported, using SW [INFO ] VB2:vb2_rsa_verify_digest() HW modexp for sig_alg 5 not supported, using SW [DEBUG] FMAP: area VBLOCK_A found @ 500000 (65536 bytes) [DEBUG] FMAP: area VBLOCK_A found @ 500000 (65536 bytes) [INFO ] VB2:vb2_verify_fw_preamble() Verifying preamble. [INFO ] VB2:vb2_digest_init() 1652 bytes, hash algo 2, HW acceleration enabled [INFO ] VB2:vb2_verify_digest() HW RSA for sig_alg 4 not supported, using SW [INFO ] VB2:vb2_rsa_verify_digest() HW modexp for sig_alg 4 not supported, using SW [INFO ] Phase 4 [DEBUG] FMAP: area FW_MAIN_A found @ 510000 (8323008 bytes) [INFO ] VB2:vb2_digest_init() 4353856 bytes, hash algo 2, HW acceleration enabled [INFO ] VB2:vb2_verify_digest() HW RSA for sig_alg 4 not supported, using SW [INFO ] VB2:vb2_rsa_verify_digest() HW modexp for sig_alg 4 not supported, using SW [DEBUG] Saving vboot hash. [INFO ] Saving nvdata [DEBUG] TPM: Extending digest for `VBOOT: boot mode` into PCR 0 [INFO ] tlcl_extend: response is 0x0 [DEBUG] TPM: Digest of `VBOOT: boot mode` to PCR 0 measured [DEBUG] TPM: Extending digest for `VBOOT: GBB HWID` into PCR 1 [INFO ] tlcl_extend: response is 0x0 [DEBUG] TPM: Digest of `VBOOT: GBB HWID` to PCR 1 measured [INFO ] tlcl_lock_nv_write: response is 0x0 [INFO ] tlcl_lock_nv_write: response is 0x0 [INFO ] Slot A is selected [DEBUG] FMAP: area FW_MAIN_A found @ 510000 (8323008 bytes) [INFO ] CBFS: mcache @0xfef89600 built for 23 files, used 0x47c of 0x2000 bytes (at this point CBFS is active) [DEBUG] FMAP: area COREBOOT found @ 1875000 (7909376 bytes) [INFO ] CBFS: mcache @0xfef87600 built for 67 files, used 0xe84 of 0x2000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x0 size 0x1ff90 in mcache @0xfef89600 [DEBUG] BS: bootblock times (exec / console): total (unknown) / 445 ms Regards, Simon

1 0

Universal Payload
by Maximilian Brune 19 Nov '23

19 Nov '23

A few months ago the topic was already in Leadership meeting + Mailinglist. It is about creating a spec that specifies the handoff between coreboot and payload via FDT. It is not just for coreboot though (u-boot, oreboot and EDK2 as well). Its been a while now, the spec grew and I don't want to keep the community in the dark. For more information here is the spec: https://docs.google.com/document/d/1WxEUlCsXpc17DkJhL3XVkOW7e_KIt_zcc9tQ1tr… Feel free to review (do your worst so that we get something decent), contribute and enter the meeting that is going on every week: https://meet.google.com/gha-shza-wnw greetings Max

1 0

[coreboot - Feature #514] (New) Determine SMM memory requirements on build time
by Patrick Georgi 17 Nov '23

17 Nov '23

Issue #514 has been reported by Patrick Georgi. ---------------------------------------- Feature #514: Determine SMM memory requirements on build time https://ticket.coreboot.org/issues/514 * Author: Patrick Georgi * Status: New * Priority: Normal * Target version: none * Start date: 2023-11-17 ---------------------------------------- When I tried to normalize the ramstage's heap size, and increase it on most platforms while doing so, I broke resume on a bunch of boards because SMM couldn't cache the ramstage properly anymore. This led to a [revert](https://review.coreboot.org/c/coreboot/+/78850) and so we're back to a few ground rules plus tons of exceptions for the heap size, all of which seem to be determined experimentally. All necessary information is known at compile time, so we should be able to verify the memory layout and make it break the build if it doesn't work out. Some thoughts that might help implement this: - We need to do a full verification if CONFIG_TSEG_STAGE_CACHE == y. - The constraints are that - CONFIG_SMM_TSEG_SIZE needs to be larger than the sum of smm (tseg code + data), CONFIG_SMM_RESERVED_SIZE, CONFIG_IED_REGION_SIZE, and AMD's HIGH_MEMORY_SCRATCH (currently: 0x30000) if CONFIG_DRIVERS_AMD_PI is enabled - CONFIG_SMM_RESERVED_SIZE must be large enough to hold ramstage + postcar + refcode (as loaded by the stage loader, ie. uncompressed) + ~64 byte overhead for IMD headers - STM has additional requirements (reach out to Eugene Myers who's our domain expert on STM), among others: - memory requirements per CPU, calculated by a formula (this could be based on CONFIG_MAX_CPUS, I guess?) - The easiest approach might be to build a tool at build time which includes config.h (so we have all the CONFIG_* around), and various coreboot library portions: - CBFS adapted to work from a file loaded from disk - IMD that works on a memory buffer (sized from CONFIG_SMM_RESERVED_SIZE) - The tool would be spliced into the build process using the build system's INTERMEDIATE facility, copying a coreboot.rom to another coreboot.rom if and only if the tool decides that the memory map is properly dimensioned. With such build time verification we should be able to clean up various memory sizing configuration values by a fair amount, so there's less variability on them. Creating a tool that computes a full memory map is more complex because it requires rebuilding/relinking a couple of stages (e.g. build ramstage to determine its size, then rebuild it with the computed memory layout that includes ramstage size) -- 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

1 0

[coreboot - Bug #513] (New) clear_memory() triggers null dereference exception when running coreboot in long (64-bit) mode
by Bill XIE 17 Nov '23

17 Nov '23

Issue #513 has been reported by Bill XIE. ---------------------------------------- Bug #513: clear_memory() triggers null dereference exception when running coreboot in long (64-bit) mode https://ticket.coreboot.org/issues/513 * Author: Bill XIE * Status: New * Priority: Low * Category: coreboot common code * Target version: master * Start date: 2023-11-17 * Affected versions: master * Affected hardware: X200 ---------------------------------------- Enabling CONFIG_USE_EXP_X86_64_SUPPORT and CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT in the mean time on my X200 triggers null dereference exception. Register dump in attached log suggests that clearing DRAM 0000000100000000-0000000180000000 triggers the exception, and the used memset() implementation in src/arch/x86/memset.c seems unable to handle such usage when built against X86_64. ---Files-------------------------------- clrmem-amd64-nulderef.log (5.21 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

2 1

[coreboot - Bug #415] RESOURCE_ALLOCATION_TOP_DOWN breaks booting
by Sean Rhodes 17 Nov '23

17 Nov '23

Issue #415 has been updated by Sean Rhodes. Martin Roth wrote in #note-6: > Is this fixed now? Technically no - it's now just disabled if the payload is edk2 ---------------------------------------- Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting https://ticket.coreboot.org/issues/415#change-1705 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master ---------------------------------------- CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files-------------------------------- resource_allocatorv4.txt (94 KB) up_squared.log (47.9 KB) hermes.log (575 KB) t500.log (585 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

1 0

[coreboot - Bug #415] RESOURCE_ALLOCATION_TOP_DOWN breaks booting
by Martin Roth 17 Nov '23

17 Nov '23

Issue #415 has been updated by Martin Roth. Is this fixed now? ---------------------------------------- Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks booting https://ticket.coreboot.org/issues/415#change-1704 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master ---------------------------------------- CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files-------------------------------- resource_allocatorv4.txt (94 KB) up_squared.log (47.9 KB) hermes.log (575 KB) t500.log (585 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

1 0

[coreboot - Documentation #426] (Resolved) Document existing and added TPM event log formats and PCR usage
by Martin Roth 17 Nov '23

17 Nov '23

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

1 0

[coreboot - Feature #425] (Resolved) Add parsing of new TPM event log formats to cbmem utility
by Martin Roth 17 Nov '23

17 Nov '23

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

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