coreboot

coreboot@coreboot.org

6 participants
39686 discussions

denverton: crash when using coreboot 4.17
by Sumo 14 Jun '22

14 Jun '22

Hi, My denverton system is crashing after the FSM memory init, probably when jumping to POSTCAR. The following lines are shown before the crash: [DEBUG] TPM: Digest of `CBFS: fallback/postcar` to PCR 2 logged [DEBUG] Loading module at 0x7f7ce000 with entry 0x7f7ce031. filesize: 0x6060 memsize: 0xc358 [DEBUG] Processing 246 relocs. Offset value of 0x7d7ce000 [DEBUG] BS: romstage times (exec / console): total (unknown) / 1350 ms Below are my CAR settings: # CONFIG_USE_DENVERTON_NS_CAR_NEM_ENHANCED is not set CONFIG_USE_DENVERTON_NS_FSP_CAR=y CONFIG_ARCH_POSTCAR_X86_32=y CONFIG_POSTCAR_STAGE=y CONFIG_CARDBUS_PLUGIN_SUPPORT=y CONFIG_FSP_CAR=y CONFIG_POSTCAR_CONSOLE=y Everything is fine when using coreboot v4.14. I have tried using CONFIG_USE_DENVERTON_NS_CAR_NEM_ENHANCED but things got even worse - in this case nothing is shown in the console output. Any suggestions? Thanks, Sumo

3 10

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

10 Jun '22

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 1489880: Control flow issues (DEADCODE) /src/mainboard/intel/adlrvp/romstage_fsp_params.c: 42 in configure_external_clksrc() ________________________________________________________________________________________________________ *** CID 1489880: Control flow issues (DEADCODE) /src/mainboard/intel/adlrvp/romstage_fsp_params.c: 42 in configure_external_clksrc() 36 * CONFIG_CLKSRC_FOR_EXTERNAL_BUFFER provides the CLKSRC that feed clock to discrete 37 * buffer for further distribution to platform. 38 */ 39 static void configure_external_clksrc(FSP_M_CONFIG *m_cfg) 40 { 41 for (unsigned int i = CONFIG_MAX_PCIE_CLOCK_SRC; i < CONFIG_MAX_PCIE_CLOCK_REQ; i++) >>> CID 1489880: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "m_cfg->PcieClkSrcUsage[i] = 6;". 42 m_cfg->PcieClkSrcUsage[i] = CONFIG_CLKSRC_FOR_EXTERNAL_BUFFER; 43 } 44 45 void mainboard_memory_init_params(FSPM_UPD *memupd) 46 { 47 FSP_M_CONFIG *m_cfg = &memupd->FspmConfig; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Open letter regarding a more open FSP codebase
by coreboot org 08 Jun '22

08 Jun '22

Hi everyone, Subrata has written a fantastic proposal for a plan to reduce the work done by the Intel FSP, and transition that work into open source implementations.[1] This would be a good initial step towards what the open source firmware communities would like to see, which is, of course, to have all the firmware to be completely open and well documented. In looking towards that goal, a group of people including myself have drafted an open letter to intel, asking that they consider Subrata’s proposal and work with us to achieve the slimming, then replacement of the FSP-S functionality with open source code [2]. The drafters of this open letter agree that this will benefit all open source firmware communities along with Intel, and ultimately their customers. I understand that some will see this as an underwhelming change, but please look at it instead as at least a step in the direction that we’d like to see. I believe that these small steps, if shown to be beneficial to Intel and their customers, will lead to larger changes, pushing the boundaries between open and proprietary codebases even further in favor of openness. If you agree with our thoughts, please take the time to read through Subrata’s proposal and the open letter to Intel, and consider adding your support behind these by signing onto the letter [2]. Thanks very much for your time, and take care. Martin [1]: https://blog.osfw.foundation/osf-intel-reduce-fsp-boundary/ [2]: https://openletter.earth/adopting-open-source-firmware-approach-for-intel-f…

3 2

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

07 Jun '22

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. 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 1 of 1 defect(s) ** CID 1489753: Null pointer dereferences (NULL_RETURNS) ________________________________________________________________________________________________________ *** CID 1489753: Null pointer dereferences (NULL_RETURNS) /src/drivers/i2c/generic/generic.c: 71 in i2c_generic_fill_ssdt() 65 printk(BIOS_ERR, "%s: ERROR: HID required\n", dev_path(dev)); 66 return; 67 } 68 69 if (config->detect) { 70 struct device *const busdev = i2c_busdev(dev); >>> CID 1489753: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be "NULL" "busdev" when calling "i2c_dev_detect". 71 if (!i2c_dev_detect(busdev, dev->path.i2c.device)) { 72 printk(BIOS_SPEW, "%s: %s at %s -- NOT FOUND, skipping\n", 73 path, 74 config->desc ? : dev->chip_ops->name, 75 dev_path(dev)); 76 return; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Announcing the coreboot 4.17 release
by coreboot org 04 Jun '22

04 Jun '22

coreboot 4.17 ======================================================================== The coreboot 4.17 release was done on June 3, 2022. Since the 4.16 release, we've had over 1300 new commits by around 150 contributors. Of those people, roughly 15 were first-time contributors. As always, we appreciate everyone who has contributed and done the hard work to make the coreboot project successful. Major Bugfixes in this release ------------------------------ * [CVE-2022-29264](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-292… New Mainboards -------------- * Clevo L140MU / L141MU / L142MU * Dell Precision T1650 * Google Craask * Google Gelarshie * Google Kuldax * Google Mithrax * Google Osiris * HP Z220 CMT Workstation * Star Labs LabTop Mk III (i7-8550u) * Star Labs LabTop Mk IV (i3-10110U and i7-10710U) * Star Labs Lite Mk III (N5000) * Star Labs Lite Mk IV (N5030) Removed Mainboards ------------------ * Google Deltan * Google Deltaur Significant or interesting changes ---------------------------------- These changes are a few that were selected as a sampling of particularly interesting commits. ### CBMEM init hooks changed Instead of having per stage x_CBMEM_INIT_HOOK, we now have only 2 hooks: * CBMEM_CREATION_HOOK: Used only in the first stage that creates cbmem, typically romstage. For instance code that migrates data from cache as ram to dram would use this hook. * CBMEM_READY_HOOK: Used in every stage that has cbmem. An example would be initializing the cbmem console by appending to what previous stages logged. The reason for this change is improved flexibility with regards to which stage initializes cbmem. ### Payloads * SeaBIOS: Update stable release from 1.14.0 to 1.16.0 * iPXE: Update stable release from 2019.3 to 2022.1 * Add "GRUB2 atop SeaBIOS" aka "SeaGRUB" option, which builds GRUB2 as a secondary payload for SeaBIOS with GRUB2 set as the default boot entry. This allows GRUB2 to use BIOS callbacks provided by SeaBIOS as a fallback method to access hardware that the native GRUB2 payload cannot access. * Add option to build SeaBIOS and GRUB2 as secondary payloads * Add new coreDOOM payload. See commit message below. ### payloads/external: Add support for coreDOOM payload coreDOOM is a port of DOOM to libpayload, based on the doomgeneric source port. It renders the game to the coreboot linear framebuffer, and loads WAD files from CBFS. ### cpu/x86/smm_module_load: Rewrite setup_stub This code was hard to read as it did too much and had a lot of state to keep track of. It also looks like the staggered entry points were first copied and only later the parameters of the first stub were filled in. This means that only the BSP stub is actually jumping to the permanent smihandler. On the APs the stub would jump to wherever c_handler happens to point to, which is likely 0. This effectively means that on APs it's likely easy to have arbitrary code execution in SMM which is a security problem. Note: This patch fixes CVE-2022-29264 for the 4.17 release. ### cpu/x86/smm_module_loader.c: Rewrite setup This code is much easier to read if one does not have to keep track of mutable variables. This also fixes the alignment code on the TSEG smihandler setup code. It was aligning the code upwards instead of downwards which would cause it to encroach a part of the save state. ### cpu/x86/smm: Add sinkhole mitigation to relocatable smmstub The sinkhole exploit exists in placing the lapic base such that it messes with GDT. This can be mitigated by checking the lapic MSR against the current program counter. ### cpu/x86/64bit: Generate static page tables from an assembly file This removes the need for a tool to generate simple identity pages. Future patches will link this page table directly into the stages on some platforms so having an assembly file makes a lot of sense. This also optimizes the size of the page of each 4K page by placing the PDPE_table below the PDE. ### cpu/x86/smm,lib/cbmem_console: Enable CBMEMC when using DEBUG_SMI This change will allow the SMI handler to write to the cbmem console buffer. Normally SMIs can only be debugged using some kind of serial port (UART). By storing the SMI logs into cbmem we can debug SMIs using 'cbmem -1'. Now that these logs are available to the OS we could also verify there were no errors in the SMI handler. Since SMM can write to all of DRAM, we can't trust any pointers provided by cbmem after the OS has booted. For this reason we store the cbmem console pointer as part of the SMM runtime parameters. The cbmem console is implemented as a circular buffer so it will never write outside of this area. ### security/tpm/crtm: Add a function to measure the bootblock on SoC level On platforms where the bootblock is not included in CBFS anymore because it is part of another firmware section (IFWI or a different CBFS), the CRTM measurement fails. This patch adds a new function to provide a way at SoC level to measure the bootblock. Following patches will add functionality to retrieve the bootblock from the SoC related location and measure it from there. In this way the really executed code will be measured. ### soc/amd/common/block/psp: Add platform secure boot support Add Platform Secure Boot (PSB) enablement via the PSP if it is not already enabled. Upon receiving psb command, PSP will program PSB fuses as long as BIOS signing key token is valid. Refer to the AMD PSB user guide doc# 56654, Revision# 1.00. Unfortunately this document is only available with NDA customers. ### drivers/intel/fsp2_0: Add native implementation for FSP Debug Handler This patch implements coreboot native debug handler to manage the FSP event messages. 'FSP Event Handlers' feature introduced in FSP to generate event messages to aid in the debugging of firmware issues. This eliminates the need for FSP to directly write debug messages to the UART and FSP might not need to know the board related UART port configuration. Instead FSP signals the bootloader to inform it of a new debug message. This allows the coreboot to provide board specific methods of reporting debug messages, example: legacy UART or LPSS UART etc. This implementation has several advantages as: 1. FSP relies on XIP 'DebugLib' driver even while printing FSP-S debug messages, hence, without ROM being cached, post 'romstage' would results into sluggish boot with FSP debug enabled. This patch utilities coreboot native debug implementation which is XIP during FSP-M and relocatable to DRAM based resource for FSP-S. 2. This patch simplifies the FSP DebugLib implementation and remove the need to have serial port library. Instead coreboot 'printk' can be used for display FSP serial messages. Additionally, unifies the debug library between coreboot and FSP. 3. This patch is also useful to get debug prints even with FSP non-serial image (refer to 'Note' below) as FSP PEIMs are now leveraging coreboot debug library instead FSP 'NULL' DebugLib reference for release build. 4. Can optimize the FSP binary size by removing the DebugLib dependency from most of FSP PEIMs, for example: on Alder Lake FSP-M debug binary size is reduced by ~100KB+ and FSP-S debug library size is also reduced by ~300KB+ (FSP-S debug and release binary size is exactly same with this code changes). The total savings is ~400KB for each FSP copy, and in case of Chrome AP firmware with 3 copies, the total savings would be 400KB * 3 = ~1.2MB. Note: Need to modify FSP source code to remove 'MDEPKG_NDEBUG' as compilation flag for release build and generate FSP binary with non-NULL FSP debug wrapper module injected (to allow FSP event handler to execute even with FSP non-serial image) in the final FSP.fd. ### security/tpm: Add vendor-specific tis functions to read/write TPM regs In order to abstract bus-specific logic from TPM logic, the prototype for two vendor-specific tis functions are added in this patch. tis_vendor_read() can be used to read directly from TPM registers, and tis_vendor_write() can be used to write directly to TPM registers. ### arch/x86: Add support for catching null dereferences through debug regs This commit adds support for catching null dereferences and execution through x86's debug registers. This is particularly useful when running 32-bit coreboot as paging is not enabled to catch these through page faults. This commit adds three new configs to support this feature: DEBUG_HW_BREAKPOINTS, DEBUG_NULL_DEREF_BREAKPOINTS and DEBUG_NULL_DEREF_HALT. ### drivers/i2c/generic: Add support for i2c device detection Add 'detect' flag which can be attached to devices which may or may not be present at runtime, and for which coreboot should probe the i2c bus to confirm device presence prior to adding an entry for it in the SSDT. This is useful for boards which may utilize touchpads/touchscreens from multiple vendors, so that only the device(s) present are added to the SSDT. This relieves the burden from the OS to detect/probe if a device is actually present and allows the OS to trust the ACPI _STA value. ### util/cbmem: Add FlameGraph-compatible timestamps output Flame graphs are used to visualize hierarchical data, like call stacks. Timestamps collected by coreboot can be processed to resemble profiler-like output, and thus can be feed to flame graph generation tools. Generating flame graph using https://github.com/brendangregg/FlameGraph: ``` cbmem -S > trace.txt FlameGraph/flamegraph.pl --flamechart trace.txt > output.svg ``` ### src/console/Kconfig: Add option to disable loglevel prefix This patch adds an option to disable loglevel prefixes. This patch helps to achieve clear messages when low loglevel is used and very few messages are displayed on a terminal. This option also allows to maintain compatibility with log readers and continuous integration systems that depend on fixed log content. If the code contains: printk(BIOS_DEBUG, "This is a debug message!\n") it will show as: [DEBUG] This is a debug message! but if the Kconfig contains: CONFIG_CONSOLE_USE_LOGLEVEL_PREFIX=n the same message will show up as This is a debug message! ### util/cbmem: add an option to append timestamp Add an option to the cbmem utility that can be used to append an entry to the cbmem timestamp table from userspace. This is useful for bookkeeping of post-coreboot timing information while still being able to use cbmem-based tooling for processing the generated data. `-a | --add-timestamp ID: append timestamp with ID\n` Additional changes ------------------ The following are changes across a number of patches, or changes worth noting, but not needing a full description. * As always, general documentation, code cleanup, and refactoring * Remove doxygen config files and targets * Get clang compile working for all x86 platforms * Work on updating checkpatch to match the current Linux version * Timestamps: Rename timestamps to make names more consistent * Continue updating ACPI code to ASL 2.0 * Remove redundant or unnecessary headers from C files * arch/x86/acpi_bert_storage.c: Use a common implementation * Postcar stage improvements * arch/x86/acpi: Consolidate POST code handling * intel/common: Enable ROM caching in ramstage * vendorcode/amd/agesa: Fix improper use of .data (const is important) * sandybridge & gm45: Support setting PCI bars above 4G Plans for Code Deprecation -------------------------- ### Intel Icelake Intel Icelake is unmaintained. Also, the only user of this platform ever was the CRB board. From the looks of it the code never was ready for production as only engineering sample CPUIDs are supported. Thus, to reduce the maintanence overhead for the community, it is deprecated from this release on and support for the following components will be dropped with the release 4.19. * Intel Icelake SoC * Intel Icelake RVP mainboard ### LEGACY_SMP_INIT As of release 4.18 (August 2022) we plan to deprecate LEGACY_SMP_INIT. This also includes the codepath for SMM_ASEG. This code is used to start APs and do some feature programming on each AP, but also set up SMM. This has largely been superseded by PARALLEL_MP, which should be able to cover all use cases of LEGACY_SMP_INIT, with little code changes. The reason for deprecation is that having 2 codepaths to do the virtually the same increases maintenance burden on the community a lot, while also being rather confusing. No platforms in the tree have any hardware limitations that would block migrating to PARALLEL_MP / a simple !CONFIG_SMP codebase. Statistics ---------- - Total Commits: 1305 - Average Commits per day: 13.42 - Total lines added: 51422 - Average lines added per commit: 39.40 - Number of patches adding more than 100 lines: 59 - Average lines added per small commit: 24.73 - Total lines removed: 66206 - Average lines removed per commit: 50.73 - Total difference between added and removed: -14784 - Total authors: 146 - New authors: 17

1 0

Open-Source Firmware Conference 2022 in Sweden, Gothenburg, September 19-21
by Christian Walter 02 Jun '22

02 Jun '22

Hi, finally! We can meet in person again. After the hackathon next week in Darmstadt, and the Linux Plumber in September, the Open-Source Firmware Conference will take place in Sweden, Gothenburg from September 19th - 21th. The Call for Participation already started and the deadline is set to the 25th of June. As you know, the OSFC is the biggest open-source firmware conference world-wide, and we would love to welcome you again in person in Gothenburg. We are looking forward to two days of conference and one day of pure hackathon - all around open-source firmware. So feel free to participate in the CfP - or just get yourself an early-bird ticket. There are also reduced community tickets (non business). Looking forward to meet you in person again! Best Regards, Chris PS: Obviously, check out https://www.osfc.io -- *Christian Walter* *Head of Firmware Development / Cyber Security * 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: christian.walter(a)9elements.com Phone: _+49 234 68 94 188 <tel:+492346894188>_ Mobile: _+49 176 70845047 <tel:+4917670845047>_ Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebastian Deutsch, Eray Basar Datenschutzhinweise nach Art. 13 DSGVO <https://9elements.com/privacy>

1 0

Fwd: [ANNOUNCEMENT] System Boot and Security Microconference at the Linux Plumbers Conference (12.–14.09.22) - CfP is open
by Paul Menzel 01 Jun '22

01 Jun '22

Dear coreboot folks, Please find a attached the call for papers for the *System Boot and Security Microconference* at the *Linux Plumbers Conference* in Dublin, September 12–14, 2022. Kind regards, Paul

1 0

Removing Yabits as a payload - Now, or after 4.19 release?
by Martin Roth 31 May '22

31 May '22

Unfortunately, yabits hasn't really seen any updates since it was added as a payload, so I think it's time to remove it. If there's no objection, we can remove it as a payload after today's 4.17 release. I don't believe this counts as deprecation, but if others feel otherwise, we can announce it in the 4.17 release notes (I'm working on those, I swear) and release it after the 4.19 release. Let me know what you think, either about the timing or about removing it period. As always, if it sees a reassurance in work, we can bring it back. Martin

3 2

Hello, coreboot general inquiries.
by mictty 31 May '22

31 May '22

tldr: OpenID does not work. Help me, sysmin. The url tells me it is to contact with the administrator. In comparison, it also seems to do with the administrator. Through Launchpad, the OpenID provider, I attempted to sign in dear your Gerrit. However, I only get this 'no found' message(https://review.coreboot.org/SignInFailure,SIGN_IN,Contact+site+admi…. Through Launchpad, I can sign in another website(not Coreboot). Can you do something for it? If your about to simply pass me the email of the administrator, you may forward to the admin instead. Best Regards, Mictty.

2 1

How to register on Coreboot Mainboard Vendor
by hechen42＠hotmail.com 31 May '22

31 May '22

Dear Coreboot team, Good days. We are an OEM&OEM Firewall mini pc manufacturer in SHENZHEN China. We are developing 2.5G firewall Mini PC hareware(we already finished them). And as Coreboot is very poweful and well knowned in firewall field so we are wonding that if we can become a coreboot registered motherboard vendor so user could use coreboot on our devices. May we know how to achieve its requirements ? Waitng for your comments and thanks a lot. Best Regards He Chen

2 1

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