coreboot

coreboot@coreboot.org

6 participants
39687 discussions

[Events] "vBeer v2" online Party! - 7th May at 3PM UTC
by Mike Banon 03 May '21

03 May '21

Dear friends, on behalf of 3mdeb I invite you to a fresh "vBeer v2"! Let's discuss the open/libre firmware/hardware and other nice embedded things you have in mind. To join us go to http://vpub.3mdeb.com/may7th on 7th May at 3PM UTC at "v1" there was a great discussion with 50 firmware masters from all over the world! Here's my blogpost [1] about it. And this time - together with your surprise suggestions (you're welcome!) - we could explore: * new advances at opensource firmware/hardware world, like this new initiative [2] for opensource FPGAs * is the new emerging RISC-V hardware such as BeagleV [3] - truly open? * results of "Ideal platform for coreboot training" survey [4] (which is still going on btw) - and much more! There'd be a productive talk with a cosy atmosphere and good vibes - so, feel invited and take your beer! ;) http://vpub.3mdeb.com/may7th , 7th May at 3PM UTC [1] https://blog.3mdeb.com/2021/2021-02-23-osf_vpub_01/ [2] https://osfpga.org/osfpga-foundation-launched/ [3] https://beagleboard.org/beaglev [4] https://corequest.limesurvey.net/274886?lang=en -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

2 1

[Survey] Ideal platform for coreboot training?
by Mike Banon 02 May '21

02 May '21

Dear Friends, please share your thoughts to help us at 3mdeb to advance a coreboot project - by participating in this opensource survey of just 7 questions: * Ideal platform for coreboot training? https://corequest.limesurvey.net/274886?lang=en Thank you very much in advance! -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

2 2

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 30 Apr '21

30 Apr '21

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. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1452766: Incorrect expression (SIZEOF_MISMATCH) /src/acpi/acpi.c: 914 in acpi_create_einj() ________________________________________________________________________________________________________ *** CID 1452766: Incorrect expression (SIZEOF_MISMATCH) /src/acpi/acpi.c: 914 in acpi_create_einj() 908 einj_smi->trigger_action_table = (u64) (uintptr_t)tat; 909 910 for (i = 0; i < ACTION_COUNT; i++) 911 printk(BIOS_DEBUG, "default_actions[%d].reg.addr is %llx\n", i, 912 default_actions[i].reg.addr); 913 >>> CID 1452766: Incorrect expression (SIZEOF_MISMATCH) >>> Passing argument "einj" of type "acpi_einj_t *" and argument "4UL /* sizeof (einj) */" to function "memset" is suspicious. 914 memset((void *)einj, 0, sizeof(einj)); 915 916 /* Fill out header fields. */ 917 memcpy(header->signature, "EINJ", 4); 918 memcpy(header->oem_id, OEM_ID, 6); 919 memcpy(header->oem_table_id, ACPI_TABLE_CREATOR, 8); ** CID 1452765: Incorrect expression (SIZEOF_MISMATCH) /src/acpi/acpi.c: 810 in acpi_create_einj() ________________________________________________________________________________________________________ *** CID 1452765: Incorrect expression (SIZEOF_MISMATCH) /src/acpi/acpi.c: 810 in acpi_create_einj() 804 acpi_einj_trigger_table_t *tat; 805 if (!header) 806 return; 807 808 printk(BIOS_DEBUG, "%s einj_smi = %p\n", __func__, einj_smi); 809 memset(einj_smi, 0, sizeof(acpi_einj_smi_t)); >>> CID 1452765: Incorrect expression (SIZEOF_MISMATCH) >>> Adding "540UL /* sizeof (acpi_einj_smi_t) */" to pointer "einj_smi" of type "acpi_einj_smi_t *" is suspicious because adding an integral value to this pointer automatically scales that value by the size, 540 bytes, of the pointed-to type, "acpi_einj_smi_t". Most likely, "sizeof (acpi_einj_smi_t)" is extraneous and should be replaced with 1. 810 tat = (acpi_einj_trigger_table_t *)(einj_smi + sizeof(acpi_einj_smi_t)); 811 tat->header_size = 16; 812 tat->revision = 0; 813 tat->table_size = sizeof(acpi_einj_trigger_table_t) + 814 sizeof(acpi_einj_action_table_t) * actions - 1; 815 tat->entry_count = actions; ** CID 1452764: Incorrect expression (SIZEOF_MISMATCH) /src/acpi/acpi.c: 931 in acpi_create_einj() ________________________________________________________________________________________________________ *** CID 1452764: Incorrect expression (SIZEOF_MISMATCH) /src/acpi/acpi.c: 931 in acpi_create_einj() 925 inj_header->einj_header_size = sizeof(acpi_injection_header_t); 926 inj_header->entry_count = ACTION_COUNT; 927 928 printk(BIOS_DEBUG, "%s einj->action_table = %p\n", 929 __func__, einj->action_table); 930 memcpy((void *)einj->action_table, (void *)default_actions, sizeof(einj->action_table)); >>> CID 1452764: Incorrect expression (SIZEOF_MISMATCH) >>> Passing argument "einj" of type "acpi_einj_t *" and argument "4U /* sizeof (einj) */" to function "acpi_checksum" is suspicious. 931 header->checksum = acpi_checksum((void *)einj, sizeof(einj)); 932 } 933 934 void acpi_create_vfct(const struct device *device, 935 acpi_vfct_t *vfct, 936 unsigned long (*acpi_fill_vfct)(const struct device *device, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Dropping the "cbfs master header" file
by Arthur Heymans 30 Apr '21

30 Apr '21

Hi Currently the "COREBOOT" FMAP cbfs region has a file named "cbfs master header" at the bottom of this fmap region and the X86 bootblock has a pointer at 0xFFFFFFFC to it. Other ARCH have a "header pointer" file at the top of that FMAP region pointing to it. Currently this file is only used as an anchor point to use cbfs with walkcbfs_asm on X86 to access cbfs in assembly (before any C code). There are 2 uses for this at the moment: 1) updating microcode on Intel systems that don't feature FIT before setting up CAR 2) finding FSP-T (if FSP_CAR is used) before jumping to it Both the cbfstool and the C coreboot code don't rely on it anymore, so it is a legacy feature. Other cbfs FMAP region like FW_MAIN_A/B in a VBOOT setup don't feature it. Accessing cbfs with walkcbfs_asm breaks hardware based root of trust security mechanisms like Intel bootguard/TXT/CBnT, because no verification or measurement whatsoever happens on either " cbfs master header" of "fsp-t" files. So for instance even if TXT/Bootguard measured or verified FSP-T as an IBB so that it is trusted, an attacker could insert a new cbfs file with the same name, "fsp-t" at a lower address and coreboot will run it anyway. So a static pointer to fsp-t is required. Sidenote/Rant: FSP-T continuously causes such integration problems... Blobs that set up the execution environment are just a very bad idea. So I propose to drop the legacy "cbfs master header" file and adapt the 2 current use cases in the following way: - Reuse the Intel FIT table and implement FIT microcode updates in assembly/software. (I had this working on some point, before I decided to use walkcbfs_asm) - Either fix the location of FSP-T via for instance a Kconfig option or add a pointer to "fsp-t" at a fixed location in the bootblock and have the tooling update the pointer during the build process. I think the Kconfig option is the least amount of work and cbfstool is already overloaded with options and flags, so my preference goes to this. Let me know what you think. Kind regards Arthur Heymans

4 4

Resource allocator v3
by Kyösti Mälkki 29 Apr '21

29 Apr '21

Hi According to Documentation/releases/coreboot-4.14-relnotes.md we are expecting following chipset deprecations due to RESOURCE_ALLOCATOR_V3: * northbridge/amd/pi/00630F01 * northbridge/amd/pi/00730F01 * northbridge/amd/pi/00660F01 (already removed) * northbridge/amd/agesa/family14 * northbridge/amd/agesa/family15tn * northbridge/amd/agesa/family16kb Any progress or any interest to get these fixed? Regards, Kyösti

3 3

Building Coreboot with Nix
by Julian Stecklina 29 Apr '21

29 Apr '21

Hi, I'm trying to build Coreboot with Nix [1] and am facing some issues. I'm wondering whether someone has already tried this before and can give some pointers. My specific problem is how to nicely package the toolchain that coreboot requires. Any hints are appreciated. :) I did discover https://nixos.wiki/wiki/Coreboot, but this doesn't help with the toolchain issue when coreboot is built as a Nix derivation... Thanks! Julian [1] https://nixos.org/

5 5

[coreboot - Cleanup #308] (New) Deal with walkcbfs_asm
by coreboot＠fe80.eu 28 Apr '21

28 Apr '21

Issue #308 has been reported by Patrick Georgi. ---------------------------------------- Cleanup #308: Deal with walkcbfs_asm https://ticket.coreboot.org/issues/308 * Author: Patrick Georgi * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- To remove the CBFS master header, walkcbfs_asm needs to either be made aware of fmap or removed. Current users (as determined by Arthur): - Updating microcode before CAR on systems that don't do µcode updates through FIT - Finding FSP-T on builds that use it (which is a bad idea anyway for root of trust concerns) -- 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 #307] (New) Support FMAP in SeaBIOS
by coreboot＠fe80.eu 28 Apr '21

28 Apr '21

Issue #307 has been reported by Patrick Georgi. ---------------------------------------- Feature #307: Support FMAP in SeaBIOS https://ticket.coreboot.org/issues/307 * Author: Patrick Georgi * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- SeaBIOS requires the CBFS master header to find the start address of the CBFS structure. It should parse the FMAP instead. -- 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 - Cleanup #306] (New) Get rid of CBFS master header
by coreboot＠fe80.eu 28 Apr '21

28 Apr '21

Issue #306 has been reported by Patrick Georgi. ---------------------------------------- Cleanup #306: Get rid of CBFS master header https://ticket.coreboot.org/issues/306 * Author: Patrick Georgi * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- The CBFS master header has been used for some basic partitioning of the flash before we established the use of FMAP. Now that FMAP is the default mechanism across the tree, we should get rid of the master header. This is a tracking issue to collect what needs to be done before we can retire the master header for good. -- 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

Intent to release coreboot 4.14 on May 10
by Patrick Georgi 26 Apr '21

26 Apr '21

Hi everybody, This email starts the release process for coreboot 4.14, so we're now at the "~2 weeks prior to release" step in our https://doc.coreboot.org/releases/checklist.html As usual, our releases don't denote any particular feature or stability milestone, they only serve two purposes: 1. Avoid the impression that coreboot is dead - an idea that actually came up before we started doing time-based releases 2. Provide anchor points that downstream coreboot users can use to base their work against if they wish to do so What everybody can do: Consider testing the devices you have against our current master branch, send in board-status reports so boards are known-good in https://coreboot.org/status/board-status.html, report or, even better, fix issues you encounter. As a developer, please consider if your large scale tree change can wait for after the release so that the tree can settle down a bit. But also, if you have large changes that are waiting (such as toolchain updates), you could already start to bring them in shape to merge after the release! Also, please check out the release notes in Documentation/releases/ coreboot-4.14-relnotes.md to see if any notable work of the last 6 months is missing there. Addition and deletion of mainboards and SoCs will be added shortly before the release with script assistance, but everything else won't be. Patches to extend our release notes are appreciated! Thanks y'all for making coreboot what it is now. As a release manager I'll merely put another label on it :-) Best regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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