coreboot

coreboot@coreboot.org

17 participants
39654 discussions

disable efficient-cores or performance-cores in Intel 12th gen processors
by baptx 28 Jun '23

28 Jun '23

Hello, For people who use the 12th generation of Intel Core processors, they may want to disable efficient-cores in the BIOS to improve performance ( https://www.reddit.com/r/intel/comments/thp7jh/disabling_the_efficiency_cor…), is it supported by coreboot or Dasharo? Some people may also want to disable performance-cores instead to save more battery ( https://www.reddit.com/r/overclocking/comments/x0xu1c/can_you_disable_perfo…), is it supported also? If some of these disabling option are not available, is there any plan to support them and is there a workaround currently? Thanks.

3 7

Legacy OS Support
by Mason McAlister 28 Jun '23

28 Jun '23

hello! any idea when Legacy OS/BIOS support is coming to Coreboot? i'd like to be able to boot legacy OSes (such as Windows 7 and below) on my chromebook, which is using MrChromebox's fork of Coreboot. i'm not "expecting" Legacy OS/BIOS support, UEFI is good enough, i think it'd just be cool if i could get windows XP or windows 7 on a chromebook. cheers! -Mason

3 2

Coreboot's stance on Purism since 2015: What changed ?
by Alexandre Janvrin 28 Jun '23

28 Jun '23

Greetings, I have been shopping around for a laptop during the past few weeks, aiming for a mix of performance and privacy. During my search, I came across a blog post by mrnuke: - https://web.archive.org/web/20150223201313/https://blogs.coreboot.org/blog/… (the post was referenced in a Qube OS discussion related to Anti Evil Maid: https://groups.google.com/g/qubes-users/c/sEmZfOZqYXM/m/j5rHeex1BAAJ) I've noticed that this post has disappeared from Coreboot's blog, and that Coreboot now advertises Purism quite differently. From https://www.coreboot.org/users.html: "Purism manufactures security focused laptops designed chip by chip to work with free/libre and open source software. Purism laptops are the only independently-made, brand new, high-performance laptops on the market specifically meant to pair recent technologies with coreboot and a neutralized Intel Management Engine." I also came across Purism's public answer: https://puri.sm/posts/about-purism-and-librems-and-cake/ I guess the change in Coreboot's stance can be explained in a few manners: - Purism genuinely improved since 2015 and is now delivering on their promises, - mrnuke's opinion never reflected Coreboot's opinions, - Purism extended a "helping" hand to Coreboot, in order to align both parties' economical objectives, From an external viewpoint, I'd say that Purism has improved on their delivery, and their narrative seems to be grounded in reality rather than smoke and mirrors. (Even though they currently admit to still having some binary blobs here and there) Can you please provide more context, and indulge in the curiosity of a random user ? (Disclaimer: I do not intend to buy a Purism laptop, not because I think they are bad, but because I'll have a more "Do It Yourself" approach) Best regards, Alexandre (a security/privacy enthusiast)

4 4

2023-06-28 - coreboot Leadership Meeting
by coreboot org 28 Jun '23

28 Jun '23

# 2023-06-28 - coreboot Leadership Attendees: DavidH, Jpmurphy, Coolstar, MattD, FelixS, WernerZ, JonathanH, StefanR, MartinR, JuliusW, RonM, KarthikR, DanielM ## Minutes: * [KyöstiM] Make build statistics downloadable from qa.coreboot.org Work to create such tar-file with timestamps and ccache stats started here: [https://review.coreboot.org/c/coreboot/+/75803](https://review.coreboot.org… * Martin will look at making the stats downloadable * [KyöstiM] Is ccache for clang intentionally disabled for coreboot-gerrit queue? I think it would be possible to configure ccache for separate gcc and clang backing storages. * Ccache was causing the build to take longer, so was disabled. Martin did look at separating the two ccache locations, but the GCC ccache is stored in ram, and there isn't typically enough memory to save both. * Look at separating GCC and clang builds into two separate builds. * Look at coverity builds - should probably only build GCC. * [coolstar] Pixel 2013 (Link) I2C bus ACPI (Windows vs Linux) * Attaches to IGD device because the i2c touchpad/touch screen are on it * Brand new drivers that are about to be submitted to MS to get signed – hardware pre-dates I2CSerialBus (which normally would be in HSW+), but new drivers on Windows use it. * It sounds like the best plan is to just push the patches and see if there are any other suggestions. * [Mailing list] Variants * There was a request on the mailing list to look at making a company’s board a variant of the CRB. We should give recommendations in the documentation about when variants should be used. * [Martin] vendors shouldn’t be under other vendors. CRBs shouldn’t be used as baseboards for other boards. * [Werner] Agree with Martin that variants should be used for whitelabel devices, but not for CRBs. * [Ron] Things are the way they are because early in the coreboot project, the other method of having vendors under CRBs was tried. The current method gives free reign to vendors to change whatever they want.Vendors like to tweak their own boards and do not like having other vendors introduce conflicting changes. * What about duplicated code and having to refactor functions out? * Ron - Sure, things can be refactored out, but deduping the code can be very tricky - it leads to a lot of #ifdefs and gets very messy. Mucking about in mainboard code may look good from an abstract firmware engineering standpoint, but leads to issues. * Daniel: Using CRBs for baseboards could work as a tree with another level, but agrees with Ron that having separate boards probably makes more sense. * Who should handle any refactoring? * Martin thinks that pushing refactoring to new coreboot engineers is going to make people want to not contribute to coreboot. * David - Definitely - can’t ask new people to rewrite as a vendor without giving any direction as to why or how, or point at a concrete example. * Ron - Agrees with David - pushing people too hard encourages forks. * Werner - could be a path to more contribution - submit initial patch, then look at rewriting. * David - teaching good code quality and coreboot standards is one thing, but pushing them without direction just leads to frustration from the new person. * Daniel - Experience shows that refactoring without understanding leads to poor refactors. We could use some documentation. Any comments could be written as documentation to help people. * David: “There are plenty of variants in the tree - look at them for examples.” is not helpful - people would have no idea which variant to look at. Especially when one doesn't exist. * Ron - stakes are much higher in firmware. It's easy to mess up and brick a bunch of systems. * Martin & David: Refactoring by beginners causes those beginners to rewrite the code in the CRB, which will lead to issues, especially if they can’t test it. * Stefan - Making code look nice is problematic and can break things. * David will write up some documentation on what was discussed here about when to use variants. Daniel & Werner can help. * Would it be interesting to have “shepherds” to help newcomers to the community? * FelixS: I’m doing this for the releases. * How time consuming is this? * The process is started 6 weeks before the release. It really varies, but typically a few hours a week. * Would people be interested in signing up to shepherd newcomers? * Matt, stefan, martin - sure * Martin will create a signup sheet * Ron, Jonathan, and Jpmurphy would be interested in shadowing until they feel confident. * Martin to send email to the mailing list with a request for additional shepherds. * Make script to help direct attention to patches (status:open and +1'd or +2'd, maybe other criteria) to help get them merged - send to mailing list periodically (weekly digest?). * [DanielM] relaying from Slack * Warner Losh: So I’m trying to understand something about a code change request I got for FreeBSD. A long time ago (2015), we committed: [https://cgit.freebsd.org/src/commit/?id=6c176113bbdd5](https://cgit.freebsd… to implement quirks for what’s not about 10-year-old chromebooks, but specified just the Acer Peppy. Later (2016), I expanded this to all coreboot instances since at the time I only knew that they were in chromebooks. Lately, we’re getting a lot of requests to add exception to the rules that are there. Starting in 2020, we started getting these. I’m wondering if there’s a better way and if people here even know what the issue is/was. DFBSD seems to have deleted all their code for this. [https://github.com/DragonFlyBSD/DragonFlyBSD/commit/ad8b9749306613f2978808b… and [https://github.com/DragonFlyBSD/DragonFlyBSD/commit/7f3d8d5546c701eceefe443… were the original dfbsd commits describing the problem with the emulated i8042. * Could someone reach out to Warner on slack? * Matt and coolstar fixed this in the EC codebase in Matt’s repo. # 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 on blogs.coreboot.org: Libreboot 20230625 released!
by blogs.coreboot.org 26 Jun '23

26 Jun '23

1 0

New on blogs.coreboot.org: No-microcode ROMs available in next Libreboot release (new stable release soon!)
by blogs.coreboot.org 26 Jun '23

26 Jun '23

1 0

[Supported Devices] Acer Aspire TC-780A?
by Techflash 21 Jun '23

21 Jun '23

Hello. I am using an Acer Aspire TC-780A, it has an Intel Core i5-7400 CPU, and is currently running BIOS RO2-B2 by AMI. The machine has UEFI support, and according to `dmidecode`, the ROM is 6MB. For the information you've requested to be sent from the wiki: ====== `lspci -tvnn` ====== -[0000:00]-+-00.0 Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [8086:591f] +-02.0 Intel Corporation HD Graphics 630 [8086:5912] +-08.0 Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model [8086:1911] +-14.0 Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller [8086:a12f] +-14.2 Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem [8086:a131] +-16.0 Intel Corporation 100 Series/C230 Series Chipset Family MEI Controller #1 [8086:a13a] +-17.0 Intel Corporation Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller [AHCI Mode] [8086:a102] +-1c.0-[01]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] +-1f.0 Intel Corporation H110 Chipset LPC/eSPI Controller [8086:a143] +-1f.2 Intel Corporation 100 Series/C230 Series Chipset Family Power Management Controller [8086:a121] \-1f.4 Intel Corporation 100 Series/C230 Series Chipset Family SMBus [8086:a123] ====== `superiotool -dV` ====== *Probing for XXX... failed* Probing for ITE Super I/O (init=standard) at 0x2e... Found ITE IT8772F (id=0x8772, rev=0x1) at 0x2e Register dump: idx 20 21 22 23 24 2e 2f val 87 72 01 01 00 00 00 def 87 72 02 00 00 00 00 LDN 0x01 (COM1) idx 30 60 61 70 f0 f1 val 00 03 f8 04 00 50 def 00 03 f8 04 00 50 LDN 0x04 (Environment controller) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 f9 fa fb val 01 0a 30 0a 20 00 20 00 20 00 00 00 f0 48 00 00 def 00 02 90 02 30 09 00 00 00 00 00 MM MM MM MM MM LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 08 def 01 00 60 00 64 01 02 08 LDN 0x06 (Mouse) idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 LDN 0x07 (GPIO) idx 25 26 27 28 29 2a 2b 2c 60 61 62 63 70 71 72 73 74 b0 b1 b2 b3 b4 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc cd e0 e1 e2 e3 e4 e9 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb val 01 0c 0e 23 c0 00 48 02 0a 10 0a 00 00 01 20 38 00 00 00 00 01 00 00 00 00 00 00 00 01 0c 0e 23 80 01 0c 0e 23 c0 23 00 00 00 00 00 07 00 00 00 00 00 2e 00 00 00 00 00 00 def 00 f3 00 00 00 00 MM 01 00 00 00 00 00 00 20 38 00 00 00 00 00 00 20 00 00 00 00 00 01 00 00 40 00 01 00 00 00 00 00 00 00 00 00 00 MM 00 00 00 00 00 00 00 00 00 00 00 00 LDN 0x0a (Consumer IR) idx 30 60 61 70 f0 val 00 00 00 00 06 def 00 03 10 0b 06 *Probing for XXX... failed* === flashrom -p internal -V === flashrom v1.2 on Linux 6.3.8-arch1-1 (x86_64) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.8.0, GCC 12.1.0, little endian Command line (3 args): flashrom -p internal -V Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Initializing internal programmer /sys/class/mtd/mtd0 does not exist No coreboot table found. Using Internal DMI decoder. No DMI table found. Found ITE Super I/O, ID 0x8772 on port 0x2e Found chipset "Intel H110" with PCI ID 8086:a143. This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... BIOS_SPI_BC = 0xa88: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x0 (SPI) Top Swap: not enabled SPI Read Configuration: prefetching enabled, caching enabled, BIOS_CNTL = 0x89: BIOS Lock Enable: disabled, BIOS Write Enable: enabled SPIBAR = 0x00007fde70a8b000 (phys = 0xfe010000) 0x04: 0xe800 (HSFS) HSFS: FDONE=0, FCERR=0, AEL=0, SCIP=0, PRR34_LOCKDN=0, WRSDIS=1, FDOPSS=1, FDV=1, FLOCKDN=1 SPI Configuration is locked down. Reading OPCODES... done 0x06: 0x0010 (HSFC) HSFC: FGO=0, HSFC=8, WET=0, FDBC=0, SME=0 0x0c: 0x00000000 (DLOCK) DLOCK: BMWAG_LOCKDN=0, BMRAG_LOCKDN=0, SBMWAG_LOCKDN=0, SBMRAG_LOCKDN=0, PR0_LOCKDN=0, PR1_LOCKDN=0, PR2_LOCKDN=0, PR3_LOCKDN=0, PR4_LOCKDN=0, SSEQ_LOCKDN=0 0x50: 0x00004acb (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0x4a, BRRA 0xcb 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-only. 0x58: 0x07ff0200 FREG1: BIOS region (0x00200000-0x007fffff) is read-write. 0x5C: 0x01ff0001 FREG2: Management Engine region (0x00001000-0x001fffff) is locked. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see https://flashrom.org/ME for details. At least some flash regions are read protected. You have to use a flash layout and include only accessible regions. For write operations, you'll additionally need the --noverify-all switch. See manpage for more details. 0xa0: 0x80 (SSFS) SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0 0xa1: 0xfe0000 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=6 0xa4: 0x0000 (PREOP) 0xa6: 0x0000 (OPTYPE) 0xa8: 0x00000000 (OPMENU) 0xac: 0x00000000 (OPMENU+4) 0xc4: 0xf3d82005 (LVSCC) LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1 0xc8: 0x20452045 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20 Enabling hardware sequencing because some important opcode is locked. OK. The following protocols are supported: Programmer-specific. Probing for Programmer Opaque flash chip, 0 kB: Hardware sequencing reports 1 attached SPI flash chip with a density of 8192 kB. Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific) mapped at physical address 0x0000000000000000. Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific). No operations were specified. Restoring PCI config space for 00:1f:5 reg 0xdc === Additional info === - Specs sheet: The best I could find is this unofficial one for the 780, not the 780A, but they're extremely similar machines as far as I can tell. https://www.manua.ls/acer/aspire-tc-780/specifications - Other relevant info: None really. If anyone would like me to try something, feel free. This machine is running Arch Linux, so anything that can run on Linux should work fine. I also have an EFI Shell binary installed, **and the official BIOS flashing EFI script from Acer**.

1 0

How to best handle new Intel Saphire Rapids server boards based on Intel Archer City?
by Paul Menzel 21 Jun '23

21 Jun '23

[Annie, Yiwei, I only added you to Cc. It’d be great if you made sure that all involved people are subscribed to the coreboot mailing list.] Dear coreboot folks, Two server boards based on Intel Archer City board, commit 30e743e7cc7f (mb/ibm: Add 4 SPR sockets server board IBM SBP1) [1], were pushed to Gerrit for review: 1. mb/inventec: Add Intel SPR server board Inventec Transformers [2] Change-Id: Ic9d99c3aadaa9f69e6d14d4b1a6c5157f5590684 2. bytedance/bd_egs (Eaglestream) [3] Change-Id: I091bc78e39cd76b3c6b9a10a1fcf58e9d671ef5d Some code seems to be copied – like bootblock.c [4] – and almost identical to the reference platform. To avoid future maintenance burden, could more knowledgeable people comment, if server boards differ drastically so separate boards are justified or if they should be made variants. I also noticed `mainboard_config_iio()`. Should that be moved to the devicetree? Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/73392 "mb/ibm: Add 4 SPR sockets server board IBM SBP1" [2]: https://review.coreboot.org/c/coreboot/+/75598 "mb/inventec: Add Intel SPR server board Inventec Transformers" [3]: https://review.coreboot.org/c/coreboot/+/75722 "mb/bytedance: Add 2 SPR sockets server board bd_egs" [4]: https://review.coreboot.org/c/coreboot/+/75598/5/src/mainboard/inventec/tra…

9 16

id.coreboot.org Keycloak server problems
by Carl-Daniel Hailfinger 21 Jun '23

21 Jun '23

Hi, I just tried to log in to Gerrit with the link "Keycloak OAuth2 (gerrit-oauth-provider plugin) <https://review.coreboot.org/login/%2Fc%2Fflashrom%2F%2B%2F50264?id=gerrit-o…>", but the redirect to https://id.coreboot.org/... gets stuck during TLS negotiation. Firefox says PR_END_OF_FILE_ERROR. Regards, Carl-Daniel

2 1

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

16 Jun '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 35 new defect(s) introduced to coreboot found with Coverity Scan. 45 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 20 of 35 defect(s) ** CID 1513104: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /src/arch/riscv/trap_handler.c: 114 in trap_handler() ________________________________________________________________________________________________________ *** CID 1513104: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /src/arch/riscv/trap_handler.c: 114 in trap_handler() 108 break; 109 } 110 } 111 void trap_handler(trapframe *tf) 112 { 113 write_csr(mscratch, tf); >>> CID 1513104: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "tf->cause & 0x8000000000000000ULL" is always 0 regardless of the values of its operands. This occurs as the logical operand of "if". 114 if (tf->cause & 0x8000000000000000ULL) { 115 interrupt_handler(tf); 116 return; 117 } 118 119 switch (tf->cause) { ** CID 1513103: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1513103: Insecure data handling (TAINTED_SCALAR) /src/security/tpm/tspi/crtm.c: 223 in recover_tpm_log() 217 218 if (ram_log == NULL) { 219 printk(BIOS_WARNING, "TPM LOG: CBMEM not available, something went wrong\n"); 220 return; 221 } 222 >>> CID 1513103: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted expression "ram_log->vendor" to "tpm_log_copy_entries", which uses it as an offset. 223 tpm_log_copy_entries(_tpm_log, ram_log); 224 } 225 CBMEM_CREATION_HOOK(recover_tpm_log); 226 #endif 227 ** CID 1513102: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1513102: Memory - corruptions (OVERRUN) /src/mainboard/ti/beaglebone/sd_media.c: 109 in boot_device_init() 103 if (init_done) 104 return; 105 106 sd_host.sd_clock_hz = 96000000; 107 sd_host.reg = (void *)MMCHS0_BASE; 108 am335x_mmc_init_storage(&sd_host); >>> CID 1513102: Memory - corruptions (OVERRUN) >>> Overrunning struct type storage_media of 152 bytes by passing it to a function which accesses it at byte offset 159. 109 storage_setup_media(&media, &sd_host.sd_mmc_ctrlr); 110 storage_display_setup(&media); 111 112 init_done = true; 113 } 114 115 const struct region_device *boot_device_ro(void) 116 { 117 return &sd_mdev.rdev; ** CID 1513101: Memory - corruptions (OVERRUN) /util/cbfstool/flashmap/fmap.c: 571 in fmap_find_test() ________________________________________________________________________________________________________ *** CID 1513101: Memory - corruptions (OVERRUN) /util/cbfstool/flashmap/fmap.c: 571 in fmap_find_test() 565 printf("FAILURE: bsearch returned false positive\n"); 566 goto fmap_find_test_exit; 567 } 568 569 /* simple test case: fmap at (total_size / 2) + 1 */ 570 offset = (total_size / 2) + 1; >>> CID 1513101: Memory - corruptions (OVERRUN) >>> Calling "memcpy" with "fmap" and "fmap_size(fmap)" is suspicious because of the very large index, 18446744073709551615. The index may be due to a negative parameter being interpreted as unsigned. [Note: The source code implementation of the function has been overridden by a builtin model.] 571 memcpy(&buf[offset], fmap, fmap_size(fmap)); 572 573 if ((unsigned)fmap_find(buf, total_size - 1) != offset) { 574 printf("FAILURE: lsearch failed to find fmap\n"); 575 goto fmap_find_test_exit; 576 } ** CID 1513100: Insecure data handling (TAINTED_SCALAR) /src/soc/intel/xeon_sp/spr/soc_acpi.c: 561 in acpi_fill_cedt() ________________________________________________________________________________________________________ *** CID 1513100: Insecure data handling (TAINTED_SCALAR) /src/soc/intel/xeon_sp/spr/soc_acpi.c: 561 in acpi_fill_cedt() 555 u32 cxl_ver; 556 u64 base; 557 558 cxl_uid.byte0 = 'C'; 559 cxl_uid.byte1 = 'X'; 560 /* Loop through all sockets and stacks, add CHBS for each CXL IIO stack */ >>> CID 1513100: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "hob->PlatformData.numofIIO" as a loop boundary. 561 for (uint8_t s = 0; s < hob->PlatformData.numofIIO; ++s) { 562 for (int x = 0; x < MAX_LOGIC_IIO_STACK; ++x) { 563 const STACK_RES *ri = &hob->PlatformData.IIO_resource[s].StackRes[x]; 564 if (!is_iio_cxl_stack_res(ri)) 565 continue; 566 /* uid needs to match with ACPI CXL device ID, eg. acpi/iiostack.asl */ ** CID 1513099: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1513099: Memory - corruptions (OVERRUN) /payloads/libpayload/arch/x86/sysinfo.c: 82 in lib_get_sysinfo() 76 lib_sysinfo.memrange[1].base = 1024 * 1024; 77 lib_sysinfo.memrange[1].size = 31 * 1024 * 1024; 78 lib_sysinfo.memrange[1].type = CB_MEM_RAM; 79 } 80 81 #if CONFIG(LP_PCI) >>> CID 1513099: Memory - corruptions (OVERRUN) >>> Overrunning struct type pci_access of 8 bytes by passing it to a function which accesses it at byte offset 15. 82 pci_init(&lib_sysinfo.pacc); 83 pci_scan_bus(&lib_sysinfo.pacc); 84 #endif 85 86 return ret; ** CID 1513098: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1513098: Memory - corruptions (OVERRUN) /src/soc/mediatek/common/mmu_operations.c: 19 in mtk_mmu_init() 13 14 /* 15 * Set 0x0 to 8GB address as device memory. We want to config IO_PHYS 16 * address to DEV_MEM, and map a proper range of dram for the memory 17 * test during calibration. 18 */ >>> CID 1513098: Memory - corruptions (OVERRUN) >>> Calling "mmu_config_range" with "NULL" and "8589934592UL" is suspicious because of the very large index, 8589934592. The index may be due to a negative parameter being interpreted as unsigned. 19 mmu_config_range((void *)0, (uintptr_t)8U * GiB, DEV_MEM); 20 21 /* SRAM is cached */ 22 mmu_config_range(_sram, REGION_SIZE(sram), SECURE_CACHED_MEM); 23 24 /* L2C SRAM is cached */ ** CID 1513097: (TAINTED_SCALAR) /src/security/tpm/tspi/log-tpm2.c: 105 in tpm2_log_dump() /src/security/tpm/tspi/log-tpm2.c: 105 in tpm2_log_dump() ________________________________________________________________________________________________________ *** CID 1513097: (TAINTED_SCALAR) /src/security/tpm/tspi/log-tpm2.c: 105 in tpm2_log_dump() 99 return; 100 101 hash_size = vb2_digest_size(TPM_MEASURE_ALGO); 102 alg_name = vb2_get_hash_algorithm_name(TPM_MEASURE_ALGO); 103 104 printk(BIOS_INFO, "coreboot TPM 2.0 measurements:\n\n"); >>> CID 1513097: (TAINTED_SCALAR) >>> Using tainted variable "le16toh(tclt->vendor.num_entries)" as a loop boundary. 105 for (i = 0; i < le16toh(tclt->vendor.num_entries); i++) { 106 struct tpm_2_log_entry *tce = &tclt->entries[i]; 107 108 printk(BIOS_INFO, " PCR-%u ", le32toh(tce->pcr)); 109 110 for (j = 0; j < hash_size; j++) /src/security/tpm/tspi/log-tpm2.c: 105 in tpm2_log_dump() 99 return; 100 101 hash_size = vb2_digest_size(TPM_MEASURE_ALGO); 102 alg_name = vb2_get_hash_algorithm_name(TPM_MEASURE_ALGO); 103 104 printk(BIOS_INFO, "coreboot TPM 2.0 measurements:\n\n"); >>> CID 1513097: (TAINTED_SCALAR) >>> Using tainted variable "le16toh(tclt->vendor.num_entries)" as a loop boundary. 105 for (i = 0; i < le16toh(tclt->vendor.num_entries); i++) { 106 struct tpm_2_log_entry *tce = &tclt->entries[i]; 107 108 printk(BIOS_INFO, " PCR-%u ", le32toh(tce->pcr)); 109 110 for (j = 0; j < hash_size; j++) ** CID 1513096: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1513096: Memory - corruptions (OVERRUN) /3rdparty/chromeec/common/usb_common.c: 576 in pd_send_hard_reset() 570 if (IS_ENABLED(CONFIG_USBC_PPC_SBU)) 571 ppc_set_sbu(port, 0); 572 } 573 574 static void pd_send_hard_reset(int port) 575 { >>> CID 1513096: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 15 by passing argument "255" in call to "task_set_event". 576 task_set_event(PD_PORT_TO_TASK_ID(port), PD_EVENT_SEND_HARD_RESET); 577 } 578 579 #ifdef CONFIG_USBC_OCP 580 581 static atomic_t port_oc_reset_req; ** CID 1513095: High impact quality (WRITE_CONST_FIELD) /3rdparty/vboot/firmware/2lib/2context.c: 39 in vb2api_init() ________________________________________________________________________________________________________ *** CID 1513095: High impact quality (WRITE_CONST_FIELD) /3rdparty/vboot/firmware/2lib/2context.c: 39 in vb2api_init() 33 return VB2_ERROR_WORKBUF_ALIGN; 34 35 if (size < vb2_wb_round_up(sizeof(*sd))) 36 return VB2_ERROR_WORKBUF_SMALL; 37 38 /* Zero out vb2_shared_data (which includes vb2_context). */ >>> CID 1513095: High impact quality (WRITE_CONST_FIELD) >>> A write to an aggregate overwrites a const-qualified field within the aggregate. 39 memset(sd, 0, sizeof(*sd)); 40 41 /* Initialize shared data. */ 42 sd->magic = VB2_SHARED_DATA_MAGIC; 43 sd->struct_version_major = VB2_SHARED_DATA_VERSION_MAJOR; 44 sd->struct_version_minor = VB2_SHARED_DATA_VERSION_MINOR; ** CID 1513094: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1513094: Memory - corruptions (OVERRUN) /src/soc/cavium/cn81xx/mmu.c: 28 in soc_mmu_init() 22 /* IO space has the MSB set and is divided into 4 sub-regions: 23 * * NCB 24 * * SLI 25 * * RSL 26 * * AP 27 */ >>> CID 1513094: Memory - corruptions (OVERRUN) >>> Calling "mmu_config_range" with "(void *)0x800000000000" and "17592186044416UL" is suspicious because of the very large index, 17592186044416. The index may be due to a negative parameter being interpreted as unsigned. 28 mmu_config_range((void *)IO_SPACE_START, IO_SPACE_SIZE, devmem); 29 30 mmu_enable(); ** CID 1513093: (OVERRUN) /src/soc/intel/common/block/acpi/cpu_hybrid.c: 57 in acpi_set_hybrid_cpu_apicid_order() /src/soc/intel/common/block/acpi/cpu_hybrid.c: 58 in acpi_set_hybrid_cpu_apicid_order() /src/soc/intel/common/block/acpi/cpu_hybrid.c: 61 in acpi_set_hybrid_cpu_apicid_order() ________________________________________________________________________________________________________ *** CID 1513093: (OVERRUN) /src/soc/intel/common/block/acpi/cpu_hybrid.c: 57 in acpi_set_hybrid_cpu_apicid_order() 51 size_t perf_core_cnt = 0, eff_core_cnt = 0; 52 int32_t eff_apic_ids[CONFIG_MAX_CPUS] = {0}; 53 extern struct cpu_info cpu_infos[]; 54 uint32_t i, j = 0; 55 56 for (i = 0; i < ARRAY_SIZE(cpu_apic_info.apic_ids); i++) { >>> CID 1513093: (OVERRUN) >>> Overrunning array "cpu_infos" of 16 8-byte elements at element index 21 (byte offset 175) using index "i" (which evaluates to 21). 57 if (cpu_infos[i].cpu->path.apic.core_type == CPU_TYPE_PERF) 58 cpu_apic_info.apic_ids[perf_core_cnt++] = 59 cpu_infos[i].cpu->path.apic.apic_id; 60 else 61 eff_apic_ids[eff_core_cnt++] = 62 cpu_infos[i].cpu->path.apic.apic_id; /src/soc/intel/common/block/acpi/cpu_hybrid.c: 58 in acpi_set_hybrid_cpu_apicid_order() 52 int32_t eff_apic_ids[CONFIG_MAX_CPUS] = {0}; 53 extern struct cpu_info cpu_infos[]; 54 uint32_t i, j = 0; 55 56 for (i = 0; i < ARRAY_SIZE(cpu_apic_info.apic_ids); i++) { 57 if (cpu_infos[i].cpu->path.apic.core_type == CPU_TYPE_PERF) >>> CID 1513093: (OVERRUN) >>> Overrunning array "cpu_infos" of 16 8-byte elements at element index 21 (byte offset 175) using index "i" (which evaluates to 21). 58 cpu_apic_info.apic_ids[perf_core_cnt++] = 59 cpu_infos[i].cpu->path.apic.apic_id; 60 else 61 eff_apic_ids[eff_core_cnt++] = 62 cpu_infos[i].cpu->path.apic.apic_id; 63 } /src/soc/intel/common/block/acpi/cpu_hybrid.c: 61 in acpi_set_hybrid_cpu_apicid_order() 55 56 for (i = 0; i < ARRAY_SIZE(cpu_apic_info.apic_ids); i++) { 57 if (cpu_infos[i].cpu->path.apic.core_type == CPU_TYPE_PERF) 58 cpu_apic_info.apic_ids[perf_core_cnt++] = 59 cpu_infos[i].cpu->path.apic.apic_id; 60 else >>> CID 1513093: (OVERRUN) >>> Overrunning array "cpu_infos" of 16 8-byte elements at element index 21 (byte offset 175) using index "i" (which evaluates to 21). 61 eff_apic_ids[eff_core_cnt++] = 62 cpu_infos[i].cpu->path.apic.apic_id; 63 } 64 65 if (perf_core_cnt > 1) 66 bubblesort(cpu_apic_info.apic_ids, perf_core_cnt, NUM_ASCENDING); ** CID 1513092: Memory - corruptions (OVERRUN) /payloads/libpayload/libc/printf.c: 799 in vsprintf() ________________________________________________________________________________________________________ *** CID 1513092: Memory - corruptions (OVERRUN) /payloads/libpayload/libc/printf.c: 799 in vsprintf() 793 /* vsnprintf_write() ensures that str will be terminated by zero. */ 794 return printf_core(fmt, &ps, ap); 795 } 796 797 int vsprintf(char *str, const char *fmt, va_list ap) 798 { >>> CID 1513092: Memory - corruptions (OVERRUN) >>> Calling "vsnprintf" with "str" and "18446744073709551615UL" is suspicious because of the very large index, 18446744073709551615. The index may be due to a negative parameter being interpreted as unsigned. [Note: The source code implementation of the function has been overridden by a builtin model.] 799 return vsnprintf(str, (size_t) - 1, fmt, ap); 800 } 801 802 int printf(const char *fmt, ...) 803 { 804 int ret; ** CID 1513091: (OVERRUN) ________________________________________________________________________________________________________ *** CID 1513091: (OVERRUN) /src/soc/intel/apollolake/elog.c: 107 in elog_gsmi_cb_platform_log_wake_source() 101 } 102 103 void elog_gsmi_cb_platform_log_wake_source(void) 104 { 105 struct chipset_power_state ps; 106 >>> CID 1513091: (OVERRUN) >>> Overrunning struct type chipset_power_state of 64 bytes by passing it to a function which accesses it at byte offset 67. 107 pmc_fill_pm_reg_info(&ps); 108 pch_log_wake_source(&ps); /src/soc/intel/jasperlake/elog.c: 188 in elog_gsmi_cb_platform_log_wake_source() 182 183 BOOT_STATE_INIT_ENTRY(BS_DEV_INIT, BS_ON_EXIT, pch_log_state, NULL); 184 185 void elog_gsmi_cb_platform_log_wake_source(void) 186 { 187 struct chipset_power_state ps; >>> CID 1513091: (OVERRUN) >>> Overrunning struct type chipset_power_state of 64 bytes by passing it to a function which accesses it at byte offset 67. 188 pmc_fill_pm_reg_info(&ps); 189 pch_log_wake_source(&ps); /src/soc/intel/skylake/elog.c: 251 in elog_gsmi_cb_platform_log_wake_source() 245 246 BOOT_STATE_INIT_ENTRY(BS_DEV_INIT, BS_ON_EXIT, pch_log_state, NULL); 247 248 void elog_gsmi_cb_platform_log_wake_source(void) 249 { 250 struct chipset_power_state ps; >>> CID 1513091: (OVERRUN) >>> Overrunning struct type chipset_power_state of 64 bytes by passing it to a function which accesses it at byte offset 67. 251 pmc_fill_pm_reg_info(&ps); 252 pch_log_wake_source(&ps); ** CID 1513090: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1513090: (TAINTED_SCALAR) /3rdparty/vboot/cgpt/cgpt_repair.c: 27 in CgptRepair() 21 22 int gpt_retval = GptValidityCheck(&drive.gpt); 23 if (params->verbose) 24 printf("GptValidityCheck() returned %d: %s\n", 25 gpt_retval, GptError(gpt_retval)); 26 >>> CID 1513090: (TAINTED_SCALAR) >>> Passing tainted expression "*drive.gpt.primary_header" to "GptRepair", which uses it as a loop boundary. 27 GptRepair(&drive.gpt); 28 if (drive.gpt.modified & GPT_MODIFIED_HEADER1) 29 printf("Primary Header is updated.\n"); 30 if (drive.gpt.modified & GPT_MODIFIED_ENTRIES1) 31 printf("Primary Entries is updated.\n"); 32 if (drive.gpt.modified & GPT_MODIFIED_ENTRIES2) /3rdparty/vboot/cgpt/cgpt_repair.c: 27 in CgptRepair() 21 22 int gpt_retval = GptValidityCheck(&drive.gpt); 23 if (params->verbose) 24 printf("GptValidityCheck() returned %d: %s\n", 25 gpt_retval, GptError(gpt_retval)); 26 >>> CID 1513090: (TAINTED_SCALAR) >>> Passing tainted expression "*drive.gpt.primary_header" to "GptRepair", which uses it as an offset. 27 GptRepair(&drive.gpt); 28 if (drive.gpt.modified & GPT_MODIFIED_HEADER1) 29 printf("Primary Header is updated.\n"); 30 if (drive.gpt.modified & GPT_MODIFIED_ENTRIES1) 31 printf("Primary Entries is updated.\n"); 32 if (drive.gpt.modified & GPT_MODIFIED_ENTRIES2) /3rdparty/vboot/cgpt/cgpt_repair.c: 27 in CgptRepair() 21 22 int gpt_retval = GptValidityCheck(&drive.gpt); 23 if (params->verbose) 24 printf("GptValidityCheck() returned %d: %s\n", 25 gpt_retval, GptError(gpt_retval)); 26 >>> CID 1513090: (TAINTED_SCALAR) >>> Passing tainted expression "*drive.gpt.secondary_header" to "GptRepair", which uses it as a loop boundary. 27 GptRepair(&drive.gpt); 28 if (drive.gpt.modified & GPT_MODIFIED_HEADER1) 29 printf("Primary Header is updated.\n"); 30 if (drive.gpt.modified & GPT_MODIFIED_ENTRIES1) 31 printf("Primary Entries is updated.\n"); 32 if (drive.gpt.modified & GPT_MODIFIED_ENTRIES2) ** CID 1513089: Integer handling issues (SIGN_EXTENSION) /src/northbridge/intel/ironlake/raminit.c: 1742 in write_testing_type2() ________________________________________________________________________________________________________ *** CID 1513089: Integer handling issues (SIGN_EXTENSION) /src/northbridge/intel/ironlake/raminit.c: 1742 in write_testing_type2() 1736 static void 1737 write_testing_type2(struct raminfo *info, u8 totalrank, u8 region, u8 block, 1738 char flip) 1739 { 1740 int i; 1741 for (i = 0; i < 2048; i++) >>> CID 1513089: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "totalrank" with type "u8" (8 bits, unsigned) is promoted in "(totalrank << 28) | (region << 25) | (block << 16) | (i << 2)" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "(totalrank << 28) | (region << 25) | (block << 16) | (i << 2)" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 1742 write32p((totalrank << 28) | (region << 25) | (block << 16) | 1743 (i << 2), get_etalon(flip, (block << 16) | (i << 2))); 1744 } 1745 1746 static u8 1747 check_testing_type2(struct raminfo *info, u8 totalrank, u8 region, u8 block, ** CID 1513088: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1513088: (TAINTED_SCALAR) /3rdparty/vboot/firmware/lib/cgptlib/cgptlib.c: 28 in GptInit() 22 retval = GptValidityCheck(gpt); 23 if (GPT_SUCCESS != retval) { 24 VB2_DEBUG("GptInit() failed validity check\n"); 25 return retval; 26 } 27 >>> CID 1513088: (TAINTED_SCALAR) >>> Passing tainted expression "*gpt->secondary_header" to "GptRepair", which uses it as a loop boundary. 28 GptRepair(gpt); 29 return GPT_SUCCESS; 30 } 31 32 int GptNextKernelEntry(GptData *gpt, uint64_t *start_sector, uint64_t *size) 33 { /3rdparty/vboot/firmware/lib/cgptlib/cgptlib.c: 28 in GptInit() 22 retval = GptValidityCheck(gpt); 23 if (GPT_SUCCESS != retval) { 24 VB2_DEBUG("GptInit() failed validity check\n"); 25 return retval; 26 } 27 >>> CID 1513088: (TAINTED_SCALAR) >>> Passing tainted expression "*gpt->primary_header" to "GptRepair", which uses it as a loop boundary. 28 GptRepair(gpt); 29 return GPT_SUCCESS; 30 } 31 32 int GptNextKernelEntry(GptData *gpt, uint64_t *start_sector, uint64_t *size) 33 { /3rdparty/vboot/firmware/lib/cgptlib/cgptlib.c: 28 in GptInit() 22 retval = GptValidityCheck(gpt); 23 if (GPT_SUCCESS != retval) { 24 VB2_DEBUG("GptInit() failed validity check\n"); 25 return retval; 26 } 27 >>> CID 1513088: (TAINTED_SCALAR) >>> Passing tainted expression "*gpt->primary_header" to "GptRepair", which uses it as an offset. 28 GptRepair(gpt); 29 return GPT_SUCCESS; 30 } 31 32 int GptNextKernelEntry(GptData *gpt, uint64_t *start_sector, uint64_t *size) 33 { ** CID 1513087: Integer handling issues (NO_EFFECT) /3rdparty/arm-trusted-firmware/lib/xlat_tables_v2/aarch64/xlat_tables_arch.c: 30 in xlat_arch_is_granule_size_supported() ________________________________________________________________________________________________________ *** CID 1513087: Integer handling issues (NO_EFFECT) /3rdparty/arm-trusted-firmware/lib/xlat_tables_v2/aarch64/xlat_tables_arch.c: 30 in xlat_arch_is_granule_size_supported() 24 { 25 unsigned int tgranx; 26 27 if (size == PAGE_SIZE_4KB) { 28 tgranx = read_id_aa64mmfr0_el0_tgran4_field(); 29 /* MSB of TGRAN4 field will be '1' for unsupported feature */ >>> CID 1513087: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "tgranx >= 0ULL". 30 return ((tgranx >= ID_AA64MMFR0_EL1_TGRAN4_SUPPORTED) && 31 (tgranx < 8U)); 32 } else if (size == PAGE_SIZE_16KB) { 33 tgranx = read_id_aa64mmfr0_el0_tgran16_field(); 34 return (tgranx >= ID_AA64MMFR0_EL1_TGRAN16_SUPPORTED); 35 } else if (size == PAGE_SIZE_64KB) { ** CID 1513086: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1513086: Memory - corruptions (OVERRUN) /payloads/libpayload/arch/arm64/mmu.c: 285 in mmu_init() 279 * To keep things simple we start with mapping the entire base 4GB as 280 * device memory. This accommodates various architectures' default 281 * settings (for instance rk3399 mmio starts at 0xf8000000); it is 282 * fine tuned (e.g. mapping DRAM areas as write-back) later in the 283 * boot process. 284 */ >>> CID 1513086: Memory - corruptions (OVERRUN) >>> Calling "mmu_config_range" with "NULL" and "4294967296UL" is suspicious because of the very large index, 4294967296. The index may be due to a negative parameter being interpreted as unsigned. 285 mmu_config_range(NULL, 0x100000000, TYPE_DEV_MEM); 286 287 for (; i < mmu_ranges->used; i++) 288 mmu_config_range((void *)mmu_ranges->entries[i].base, 289 mmu_ranges->entries[i].size, 290 mmu_ranges->entries[i].type); ** CID 1513085: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1513085: Memory - corruptions (OVERRUN) /src/soc/qualcomm/sc7280/mmu.c: 14 in sc7280_mmu_init() 8 #include <soc/symbols_common.h> 9 10 void sc7280_mmu_init(void) 11 { 12 mmu_init(); 13 >>> CID 1513085: Memory - corruptions (OVERRUN) >>> Calling "mmu_config_range" with "(void *)0x1000" and "4294963200UL" is suspicious because of the very large index, 4294963200. The index may be due to a negative parameter being interpreted as unsigned. 14 mmu_config_range((void *)(4 * KiB), ((4UL * GiB) - (4 * KiB)), DEV_MEM); 15 mmu_config_range((void *)_ssram, REGION_SIZE(ssram), CACHED_RAM); 16 mmu_config_range((void *)_bsram, REGION_SIZE(bsram), CACHED_RAM); 17 mmu_config_range((void *)_dma_coherent, REGION_SIZE(dma_coherent), 18 UNCACHED_RAM); 19 20 mmu_enable(); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

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