coreboot

coreboot@coreboot.org

6 participants
39686 discussions

Can't write new comments under "payloads/cbui: Add new payload CBUI" change
by Mike Banon 28 Jul '23

28 Jul '23

Good day! So, I found this Gerrit change: https://review.coreboot.org/c/coreboot/+/23586 - payloads/cbui: Add new payload CBUI Wanted to reply " Not tested yet, but looks like a nice idea " but got this: Error 400 (Bad Request): One or more comments were rejected in validation: Exceeding maximum number of comments: 5139 (existing) + 2 (new) > 5000 This issue might be blocking the further work on this change (and I don't see why there should be any limit at all) -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

[PATCH] firmware: coreboot: framebuffer: Allow building with simpledrm
by Alper Nebi Yasak 25 Jul '23

25 Jul '23

The coreboot framebuffer driver registers a "simple-framebuffer" device based on the information from the firmware, after checking that it's compatible with the formats listed in simplefb.h. It was added before simpledrm, and its Kconfig marked as dependent on the simplefb driver. The simpledrm driver can also handle "simple-framebuffer" devices and the coreboot framebuffer works fine with it on a 'Lick' Chromebook. Allow building the coreboot framebuffer driver with simpledrm as well. Signed-off-by: Alper Nebi Yasak <alpernebiyasak(a)gmail.com> --- drivers/firmware/google/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/google/Kconfig b/drivers/firmware/google/Kconfig index 1bc7cbf2f65d..41b78f5cb735 100644 --- a/drivers/firmware/google/Kconfig +++ b/drivers/firmware/google/Kconfig @@ -59,7 +59,7 @@ config GOOGLE_MEMCONSOLE_X86_LEGACY config GOOGLE_FRAMEBUFFER_COREBOOT tristate "Coreboot Framebuffer" - depends on FB_SIMPLE + depends on FB_SIMPLE || DRM_SIMPLEDRM depends on GOOGLE_COREBOOT_TABLE help This option enables the kernel to search for a framebuffer in -- 2.40.1

2 1

sources about coreboot devicetree
by bejjeh315＠yahoo.com 25 Jul '23

25 Jul '23

Hi I want to fully understand the structure of coreboot devicetree and to be able to make chenges, but I couldn't find much resources, only two pages helped me some.. my first question is about resources to learn this.. My second, there are other videos and things talking about devicetree in linux (which I know is different from the corebootie one), do you think reading these ones is helpful for me? or for example learning ASL helps? I'm a newbie in the hardware...

2 1

regarding virtualization support in coreboot
by ritul guru 25 Jul '23

25 Jul '23

Hi, Does coreboot support virtualization features like SVM, AMD SEV, hard level virtualization SR-IOV? *Thanks & RegardsRitul Guru*

2 1

Recent commit c202be7 ( payloads/external/LinuxBoot: Clean up ) breaks " make clean "
by Ivan Ivanov 24 Jul '23

24 Jul '23

Good day, friends! After getting this recent commit, doing " make clean " is not possible in a coreboot directory - I get this error now: ~/coreboot$ make clean /bin/sh: 1: go: not found /bin/sh: 1: go: not found /bin/sh: 1: [: -eq: unexpected operator Looks like there's a problem in some script Best regards, Ivan Ivanov

2 1

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

18 Jul '23

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. 1 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 1518044: API usage errors (SWAPPED_ARGUMENTS) ________________________________________________________________________________________________________ *** CID 1518044: API usage errors (SWAPPED_ARGUMENTS) /src/northbridge/intel/ironlake/northbridge.c: 125 in mc_read_resources() 119 pci_read_config32(pcidev_on_root(0, 0), IGD_BASE); 120 gtt_base = 121 pci_read_config32(pcidev_on_root(0, 0), GTT_BASE); 122 if (gtt_base > tseg_end) { 123 /* Reserve the gap. MMIO doesn't work in this range. Keep 124 it uncacheable, though, for easier MTRR allocation. */ >>> CID 1518044: API usage errors (SWAPPED_ARGUMENTS) >>> The positions of arguments in the call to "mmio_from_to" do not match the ordering of the parameters: * "tseg_end" is passed to "base". * "gtt_base" is passed to "end". 125 mmio_from_to(dev, index++, tseg_end, gtt_base); 126 } 127 mmio_range(dev, index++, gtt_base, uma_size_gtt * MiB); 128 mmio_range(dev, index++, igd_base, uma_size_igd * MiB); 129 130 upper_ram_end(dev, index++, touud * MiB); ** CID 1518043: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/intel/ironlake/northbridge.c: 128 in mc_read_resources() ________________________________________________________________________________________________________ *** CID 1518043: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/intel/ironlake/northbridge.c: 128 in mc_read_resources() 122 if (gtt_base > tseg_end) { 123 /* Reserve the gap. MMIO doesn't work in this range. Keep 124 it uncacheable, though, for easier MTRR allocation. */ 125 mmio_from_to(dev, index++, tseg_end, gtt_base); 126 } 127 mmio_range(dev, index++, gtt_base, uma_size_gtt * MiB); >>> CID 1518043: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "uma_size_igd * 1048576" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 128 mmio_range(dev, index++, igd_base, uma_size_igd * MiB); 129 130 upper_ram_end(dev, index++, touud * MiB); 131 132 /* This memory is not DMA-capable. */ 133 if (touud >= 8192 - 64) ** CID 1518042: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/intel/ironlake/northbridge.c: 127 in mc_read_resources() ________________________________________________________________________________________________________ *** CID 1518042: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/intel/ironlake/northbridge.c: 127 in mc_read_resources() 121 pci_read_config32(pcidev_on_root(0, 0), GTT_BASE); 122 if (gtt_base > tseg_end) { 123 /* Reserve the gap. MMIO doesn't work in this range. Keep 124 it uncacheable, though, for easier MTRR allocation. */ 125 mmio_from_to(dev, index++, tseg_end, gtt_base); 126 } >>> CID 1518042: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "uma_size_gtt * 1048576" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 127 mmio_range(dev, index++, gtt_base, uma_size_gtt * MiB); 128 mmio_range(dev, index++, igd_base, uma_size_igd * MiB); 129 130 upper_ram_end(dev, index++, touud * MiB); 131 132 /* This memory is not DMA-capable. */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

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

14 Jul '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 4 new defect(s) introduced to coreboot found with Coverity Scan. 1 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 4 of 4 defect(s) ** CID 1517819: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/common/block/systemagent/systemagent.c: 243 in imr_resource() ________________________________________________________________________________________________________ *** CID 1517819: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/common/block/systemagent/systemagent.c: 243 in imr_resource() 237 size_k = ((~mask & 0x0fffffff) + 1); 238 /* 239 * IMRs sit in lower DRAM. Mark them cacheable, otherwise we run 240 * out of MTRRs. Memory reserved by IMRs is not usable for host 241 * so mark it reserved. 242 */ >>> CID 1517819: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "base_k * 1024U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 243 reserved_ram_range(dev, idx, base_k * KiB, size_k * KiB); 244 } 245 246 /* 247 * Add IMR ranges that hang off the host bridge/memory 248 * controller device in case CONFIG(SA_ENABLE_IMR) is selected by SoC. ** CID 1517818: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/intel/i440bx/northbridge.c: 65 in i440bx_domain_read_resources() ________________________________________________________________________________________________________ *** CID 1517818: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/intel/i440bx/northbridge.c: 65 in i440bx_domain_read_resources() 59 tolmk = tomk; 60 } 61 62 /* Report the memory regions. */ 63 idx = 10; 64 ram_range(dev, idx++, 0, 0xa0000); >>> CID 1517818: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "tolmk * 1024UL" with type "unsigned long" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 65 ram_from_to(dev, idx++, 0xc0000, tolmk * KiB); 66 } 67 } 68 69 static struct device_operations pci_domain_ops = { 70 .read_resources = i440bx_domain_read_resources, ** CID 1517817: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/mainboard/emulation/qemu-riscv/mainboard.c: 17 in mainboard_enable() ________________________________________________________________________________________________________ *** CID 1517817: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/mainboard/emulation/qemu-riscv/mainboard.c: 17 in mainboard_enable() 11 12 if (!dev) { 13 die("No dev0; die\n"); 14 } 15 16 dram_mb_detected = probe_ramsize((uintptr_t)_dram, CONFIG_DRAM_SIZE_MB); >>> CID 1517817: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "dram_mb_detected * 1048576U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 17 ram_range(dev, 0, (uintptr_t)_dram, dram_mb_detected * MiB); 18 } 19 20 struct chip_operations mainboard_ops = { 21 .enable_dev = mainboard_enable, ** CID 1517816: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/common/block/systemagent/systemagent.c: 243 in imr_resource() ________________________________________________________________________________________________________ *** CID 1517816: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/intel/common/block/systemagent/systemagent.c: 243 in imr_resource() 237 size_k = ((~mask & 0x0fffffff) + 1); 238 /* 239 * IMRs sit in lower DRAM. Mark them cacheable, otherwise we run 240 * out of MTRRs. Memory reserved by IMRs is not usable for host 241 * so mark it reserved. 242 */ >>> CID 1517816: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "size_k * 1024U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 243 reserved_ram_range(dev, idx, base_k * KiB, size_k * KiB); 244 } 245 246 /* 247 * Add IMR ranges that hang off the host bridge/memory 248 * controller device in case CONFIG(SA_ENABLE_IMR) is selected by SoC. ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

2023-07-12 - coreboot Leadership meeting minutes
by coreboot org 12 Jul '23

12 Jul '23

# 2023-07-12 - coreboot Leadership Attendees: David Hendricks, Felix Held, Jay Talbott, Jonathon Hall, Julius Werner, Martin Roth, Patrick Georgi, Simon Glass, Tim Crawford, Werner Zeh * [KyöstiM] Someone with access to Intel Meteor Lake documentation, is there a better workaround or documented errata for the XAPIC/X2APIC issue in bringing up AP CPUs? \ [https://review.coreboot.org/c/coreboot/+/76384](https://review.coreboot.org… * Nobody chimed in on the meeting. Hope folks follow up on the CL or mailing list * [FelixS] Doing some work on the toolchain and build system * [CB:76401](https://review.coreboot.org/c/coreboot/+/76401) reduces the build time for the coreboot-toolchain builder from ~6 hrs to 1.5 hrs * Awesome! * Clang / scan-build has support for the z3 solver for static analysis. Does anyone have experience with it? * It reports less false-positives, but it is slower. There seems to be some kind of hybrid mode. * Shouldn't be a problem since Martin will move it to another builder * Larger shuffle planned between build nodes * codechecker enables it by default if available * Let’s try it out? * FelixS visited Hetzner and used the chance to promote coreboot, they were quite positive and interested in helping us * Let’s set up a call with them? Martin seems interested but isn’t a server person (except for being a marvelous admin) * David, Ron, perhaps? * Werner wants clarity on what they want or what they can provide. Needs a contact and would reach out then. * [PaulM] Is there an overview of the received and spent money? * SFC provides bookkeeping service * Stefan has access * Is there a particular area of interest with this? * [PaulM] The changes regarding renaming master to main were never announced on the list. * It was likely buried in the meeting minutes * Nothing's been done yet, it's been a future objective for a while. Once we have a schedule it will be announced. * [PaulM] Besides OSFC, are people going to other conferences? * Companies aren't paying for people to go to conferences as much as before * Upcoming events: Coscup (Taiwan), OCP Fall Summit (San Jose area) the week after OSFC (also in San Jose area) * Martin: Add these events to the coreboot calendar * Martin can add them if somebody provides dates, times, info * Make sure to include specific talks that will be given relevant to coreboot * Call for papers for OSFC expires soon (July 16) * [Simon Glass] Implementing [Firmware Handoff](https://github.com/FirmwareHandoff/firmware_handoff) in coreboot * Moving some OS/FW communications into a common runtime * Helps do things like enable serial console in a universal manner * How is this different from universal payload? * Universal Payload uses a device tree as a handoff mechanism. This doesn't need device tree, it could be a C structure you can pass along * Not as heavyweight as full handoff * This is not competing with universal payload. DT is good when transferring complex information between projects. This is good when you're in a constrained (e.g. pre-RAM) environment or when it doesn't make sense to have the overhead of DT. * Trusted Firmware will use this, coreboot will have an implementation * "A coreboot table by another name" * The coreboot implementation would just write the tables needed by trusted firmware. * Would this replace coreboot tables? * Julius: We wouldn’t want to have two separate copies of the same information generated * Martin: Wouldn’t we want to generate once, into the coreboot tables, then translate into whatever we wanted, like we requested for the Universal Payload? * Would this replace the cmos setup options? * Not currently, but the android team has implemented something that does that. * This would pass information between stages, at least to the point that the universal payload * Julius: It would make more sense to expand cbmem and expand it into early environments. * Simon: cbmem isn’t set up in bootblock currently. * Would coreboot ever need to accept (consume) firmware handoff tables? * It’s not clear. * [Simon Glass] Drop corebook-sdk? * What coreboot-sdk does * Provides environment with tested toolchain * Can be used in Windows, FreeBSD, etc. * kernel.org publishes things used to build the kernel and other firmware projects * Faster to download than to build * Also need to support ADA (libgfxinit), Rust, Go (SBOM stuff, 9elements security tooling) * [David] Mainboard variants doc coming along nicely, will hopefully convert to markdown and upload to Gerrit in ~1-2 months: * [https://review.coreboot.org/c/coreboot/+/76200/](https://review.coreboot.or… * [https://docs.google.com/document/d/1ELrZ7WKkZn6zCA9mdpVC6Ze47pg-gvTHanDfLMU… * [Martin, FelixS] We're about 6 weeks out from the next release # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

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

07 Jul '23

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 1516782: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1516782: (TAINTED_SCALAR) /util/cbmem/cbmem.c: 1051 in dump_tpm_std_log() 1045 1046 tcg_spec_entry = event_log; 1047 if (!strcmp((const char *)tcg_spec_entry->signature, TCG_EFI_SPEC_ID_EVENT_SIGNATURE)) { 1048 if (tcg_spec_entry->spec_version_major == 2 && 1049 tcg_spec_entry->spec_version_minor == 0 && 1050 le32toh(tcg_spec_entry->event_type) == EV_NO_ACTION) { >>> CID 1516782: (TAINTED_SCALAR) >>> Passing tainted expression "tcg_spec_entry->num_of_algorithms" to "parse_tpm2_log", which uses it as an offset. 1051 parse_tpm2_log(tcg_spec_entry); 1052 } else { 1053 fprintf(stderr, "Unknown TPM2 log specification.\n"); 1054 } 1055 unmap_memory(&log_mapping); 1056 return; /util/cbmem/cbmem.c: 1051 in dump_tpm_std_log() 1045 1046 tcg_spec_entry = event_log; 1047 if (!strcmp((const char *)tcg_spec_entry->signature, TCG_EFI_SPEC_ID_EVENT_SIGNATURE)) { 1048 if (tcg_spec_entry->spec_version_major == 2 && 1049 tcg_spec_entry->spec_version_minor == 0 && 1050 le32toh(tcg_spec_entry->event_type) == EV_NO_ACTION) { >>> CID 1516782: (TAINTED_SCALAR) >>> Passing tainted expression "tcg_spec_entry->digest_sizes" to "parse_tpm2_log", which uses it as a loop boundary. 1051 parse_tpm2_log(tcg_spec_entry); 1052 } else { 1053 fprintf(stderr, "Unknown TPM2 log specification.\n"); 1054 } 1055 unmap_memory(&log_mapping); 1056 return; /util/cbmem/cbmem.c: 1038 in dump_tpm_std_log() 1032 tspec_entry = event_log; 1033 if (!strcmp((const char *)tspec_entry->signature, TCPA_SPEC_ID_EVENT_SIGNATURE)) { 1034 if (tspec_entry->spec_version_major == 1 && 1035 tspec_entry->spec_version_minor == 2 && 1036 tspec_entry->spec_errata >= 1 && 1037 le32toh(tspec_entry->entry.event_type) == EV_NO_ACTION) { >>> CID 1516782: (TAINTED_SCALAR) >>> Passing tainted expression "tspec_entry->vendor_info_size" to "parse_tpm12_log", which uses it as an offset. 1038 parse_tpm12_log(tspec_entry); 1039 } else { 1040 fprintf(stderr, "Unknown TPM1.2 log specification\n"); 1041 } 1042 unmap_memory(&log_mapping); 1043 return; /util/cbmem/cbmem.c: 1038 in dump_tpm_std_log() 1032 tspec_entry = event_log; 1033 if (!strcmp((const char *)tspec_entry->signature, TCPA_SPEC_ID_EVENT_SIGNATURE)) { 1034 if (tspec_entry->spec_version_major == 1 && 1035 tspec_entry->spec_version_minor == 2 && 1036 tspec_entry->spec_errata >= 1 && 1037 le32toh(tspec_entry->entry.event_type) == EV_NO_ACTION) { >>> CID 1516782: (TAINTED_SCALAR) >>> Passing tainted expression "tspec_entry->vendor_info" to "parse_tpm12_log", which uses it as a loop boundary. 1038 parse_tpm12_log(tspec_entry); 1039 } else { 1040 fprintf(stderr, "Unknown TPM1.2 log specification\n"); 1041 } 1042 unmap_memory(&log_mapping); 1043 return; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

All Systems Go! 2023 (Berlin, 13/14. 09. 23): Call for Participation ends July 7th
by Paul Menzel 05 Jul '23

05 Jul '23

Dear coreboot folks, *Networking* is also a topic for the ASG! conference. > All Systems Go! 2023 Call for Proposals > > The Call for Participation (CFP) for All Systems Go! 2023 is now > open! Please submit your proposals for consideration. > > The CFP will close on July 7th, 2023. A response will be sent to all > submitters on or before July 14th, 2023. The conference takes place > in 🗺️ Berlin, Germany 🇩🇪 on Sept. 13-14th. > > All Systems Go! 2023 is all about foundational open-source Linux > technologies. We are primarily looking for deeply technical talks by > and for developers, engineers and other technical roles. > > We focus on the userspace side of things, so while kernel topics are > welcome they must have clear, direct relevance to userspace. The > following is a non-comprehensive list of topics encouraged for 2023 > submissions: > > * Image-Based Linux 🖼️ > * Secure and Measured Boot 📏 > * TPM-Based Local/Remote Attestation, Encryption, Authentication 🔑 > * Low-level container executors and infrastructure ⚙️. > * IoT, embedded and server Linux infrastructure > * Reproducible builds 🔧 > * Package management, OS, container 📦, image delivery and updating > * Building Linux devices and applications 🏗️ > * Low-level desktop 💻 technologies > * Networking 🌐 > * System and service management 🚀 > * Tracing and performance measuring 🔍 > * IPC and RPC systems 🦜 > * Security 🔐 and Sandboxing 🏖️ > > Format: submissions must be in one of three formats: 35min talk + 5 > min Q&A, 20min talk + 5 min Q&A, and 5min lightning talks. > > Please familiarize yourself with our Code of Conduct as all speakers > and attendees are expected to abide by it. > > You can enter proposals until 2023-07-07 23:59 (UTC) Some community members are even located in Berlin, and a lot in Germany or Poland, so it is a great way to make coreboot and FLOSS firmware more known. I am planning on submitting a lightning talk about coreboot, but if somebody is also interested in giving a longer talk, and does not want to do it alone, please ping me. Kind regards, Paul [1]: https://cfp.all-systems-go.io/all-systems-go-2023/cfp

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