coreboot

coreboot@coreboot.org

6 participants
39686 discussions

coreboot has switched the default git branch from "master" to "main"
by coreboot org 12 Sep '23

12 Sep '23

Hello all. As was mentioned in the 4.21 release notes, coreboot has switched the default branch from "master" to "main". We're currently in the process of updating the documentation and scripts in the coreboot repository, but anyone running scripts of their own will need to update them to point to the main branch. To change your coreboot local tree, see what's in your git config: /work/git/coreboot ((dc75d3e6c1...))% git config -l | grep master remote.origin.push=HEAD:refs/for/master branch.master.remote=origin branch.master.merge=refs/heads/master branch.master.rebase=true You can edit your .git/config file to change these to main, or do it from the command line: git config remote.origin.push HEAD:refs/for/main git config --remove-section branch.master git config branch.main.remote origin git config branch.main.merge refs/heads/main git config branch.main.rebase true In general, this name change shouldn't create any significant impact. Basically anything you previously used "master" for, you should change to "main". Instead of using "push origin HEAD:refs/for/master" you'll now use "push origin HEAD:refs/for/main". Instead of checking out or rebasing on master, you'll now use main. All of the open coreboot patches in gerrit have been updated to be pushed to main when merged. The master branch will no longer accept pushes. We will keep the master branch in sync with the main branch for a while so that everyone has time to switch any scripts that are running over to the main branch, but this will be discontinued at some point - probably around the end of November, after the 4.22 release. If you have any questions or issues about how to do things relating to this change, please feel free to reply to this message and we'll try to help solve any issues. Martin

3 2

Patches moved to main branch lost review scores
by Compostella, Jeremy 12 Sep '23

12 Sep '23

Hi, Most of my gerrit patches moved to the main branch over the week-end. But they lost reviews score such +2 or V+1. Typically, <https://review.coreboot.org/c/coreboot/+/77615>. If V+1 is mandatory how do I trigger the Jenkins gerrit build ? Regards, -- *Jeremy* /One Emacs to rule them all/

3 2

2023-08-23 - coreboot Leadership meeting minutes
by coreboot org 11 Sep '23

11 Sep '23

# 2023-08-23 - coreboot Leadership # Attendees: * ChrisW, MartinR, SubrataB, WernerZ, JonathanH, PatrickG, PaulP, JeremyC, KapilP, AnilK, HannahW, JasonG, RajA, FelixH, SimonG, JayT, JuliusW, ShelleyC, Nico, DavidH, MaximilianB, PratikkumarP, JonM, VincentZ, StefanR, MarshallD, ArthurH, FelixS # Minutes: ## [Subrata] Intel AP FW team would like to present the uGOP **implementation** meant for early Sign of Life (SOL). * The support commitment about libgfxinit is not strong from Intel management hence, Intel wished to leverage existing GFX PEIM in a much smaller format to support early display init. I’m hoping to invite the Intel team to present the talk. * [Martin] I’m not sure that we want to replace an open source solution with a proprietary solution. If we can get the uGOP source code opened, that would be ideal, but I can’t imagine how difficult that would be. * Discussion was started on the mailing list _[RFC] Pre-Memory Sign-of-Life using Intel uGOP_: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/4OS4… * [sjg] Has there been discussion of libgfxinit in C? * https://code.google.com/archive/p/i915tool/source/default/source * https://review.coreboot.org/c/coreboot/+/76762 * The root cause is long memory-training times on recent Intel devices. For AMD it is around 1 second per GB, but Intel takes longer * The uGOP driver is needed to show graphics during the long DDR5 Initialization. * Why can’t the uGOP driver be in the FSPM? * An API needs to be exposed. * Intel wants to have a unified interface between coreboot & UEFI firmware, which is why they want to use the uGOP driver. * So why can’t the uGOP driver be open source? * Because of intel. Maybe in a year the situation will have changed. * This isn’t coreboot’s problem. The Meteor Lake GPU VPU Linux driver was [open sourced last year](https://patchwork.kernel.org/project/dri-devel/patch/20220728131709.1…. * Release the information, and the community can help. * The uGOP is needed for early bringup of the chip, but Google needs the uGOP driver for the length of the program, because any other possibility won’t be tested. * The uGOP driver allows comparison with libgfxinit. * But we can already compare libgfxinit with the full GOP driver. * Again, why should the coreboot community care? * The only way we can get Intel to change and actually support open source is by putting our foot down now and refusing the uGOP driver. Intel has *no* incentive to change otherwise. * coreboot does *NOT* want another blob. Intel keeps telling coreboot that it’s just not possible or that it’s going to take too long, but if they had started on a previous project, they’d be ready now. * Intel: Not able to make changes for current platform but may consider them in future. * [Patrick] Same answer as in the last 13 years. Nothing ever happens (and I don’t blame the messengers, I fully believe that they try) ## [FelixS] Broken Matrix/IRC bridge * Bridge is disconnected from IRC and will not be coming back soon. What can we do for coreboot? * Can we set up our own matrix bridge. We can do this, but need to work out the details. * GDPR may be a concern (need to limit data collection). ## [Martin]How do we want to handle renaming I2C master/slave to controller/target. The I2C Spec has changed the names, but most datasheets have not. * Should we rename everything I2C across all of coreboot so that the naming is consistent inside coreboot, but register names are different from datasheets. * Should we leave the master/slave terminology for registers so they match the datasheets, and have the mismatch inside of coreboot. * https://review.coreboot.org/c/coreboot/+/77098 * Julius and Arthur vote to leave the register names using the terminology from their datasheets. * [Nic] This seems to be in line with what is published on https://doc.coreboot.org/community/language_style.html * Consensus during meeting: Keep drivers consistent with datasheets, however the higher-level APIs can use the newer language. ## [Martin] Does anyone know if the workaround for xeon_sp/spr: Enable BROKEN_FSP_NEEDS_STACK_ABOVE_BSS is still needed? * https://review.coreboot.org/c/coreboot/+/61164/3 * Arthur can look to see. ## [Martin] A while back, we discussed trying to help people with patches to keep things from getting stale. Over the past several weeks, I’ve been trying to review things that are starting to get a little old. While this can be cumbersome with long patch trains, I think it’s very useful overall. Here are the searches I’ve been using: * [cb_review_1_week_ignore_starred](https://review.coreboot.org/q/repo:coreboo… * [cb_review_1_week](https://review.coreboot.org/q/repo:coreboot+AND+status:op… * [cb_review_2_weeks](https://review.coreboot.org/q/repo:coreboot+AND+status:o… * The 1 week search filters out a lot of patches - anything with open comments, anything that isn’t verified, anything with open comments. * The 2 week patch just filters WIP and anything over 3 months old. * I’ve been trying to keep fresh patches from getting over 7 days old. ## [Martin] Within AMD, we’ve been discussing the licensing for the APCB (AMD PSP Customization Block) blobs. We believe that they should be licensed similar to how we license the vbt.bin files - as pure configuration data. Currently we’re using the CC-PDDC license for those files, and including them in the main coreboot repository. How would people feel about doing the same with the APCB files? * APCB configuration tooling isn’t public, so the data block itself is the best that can be offered * Still, it’s only data (like SPD or VBT) * Concern if this is data that ought to be changed more often than, say, SPD? * It makes sense to keep APCB with mainboard, but user should be aware that APCB may get reconfigured at runtime, thus it will not necessarily match the blob stored in the repo. ## [FelixS] [https://felixsinger.github.io/bootguard-status/](https://felixsinger.github… * People often ask on which boards coreboot can be ported on or if their boards can be supported by coreboot. * This tracks hardware which has BootGuard enabled or disabled. * What do people think of this? Would it be reasonable to host this at a coreboot.org domain? * Yes, but let’s make it more generic to support other companies. * Maybe merge with the board-status list? * This is autogenerated, so it would be difficult. * Let’s put it on coreboot.org as it is now, but update it for other platforms. ## [Paul] Please let’s use the mailing list more. Some topics on the agenda could be discussed there first. The agenda sometimes looks like a different/alternative forum. * It’s easier to discuss things in the meeting by speaking than having to write an email. * People should look at the agenda, and add arguments here before the meeting, such as the discussion about renaming I2c. This does help shorten the meetings. ## [Paul] Experienced reviewers from coreboot companies? Who replaced Aaron, Furqan and Tim? Currently my feeling is, only 9elements does “deep” review for the general code base. * It’s hard to get the experience to do the in-depth reviews - When experienced people leave the companies, it’s hard to replace them * [David] Need to recruit more people to develop coreboot professionally. * FelixH and MartinR review everything they merge pretty thoroughly. ## [Paul] Early MRC caching: https://review.coreboot.org/c/coreboot/+/77295 * New Kconfig option or should integration with all platforms be evaluated first * (Ran out of time, we’ll discuss on the mailing list.) ## [Paul] Status amount of funds and spending thereof. * (Ran out of time, we’ll discuss on the mailing list.) ## [Kyösti] Public document, or some other approach, needed to complete review of Intel Thunderbolt: https://review.coreboot.org/c/coreboot/+/75286 * Add JeremyC to the review, and he can try to help find someone. * Bring up on the mailing list so the people at intel have more visibility. # 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…

9 17

[coreboot - Bug #175] Most USB3 external disk enclosures do not work with coreboot on X230
by Robert Alessi 10 Sep '23

10 Sep '23

Issue #175 has been updated by Robert Alessi. Patrick Rudolph wrote in #note-3: > The RCBA register for USB seems fine, but we don't do that much xhci initialisation in coreboot. > From the error description I guess it's related to over-current or transmitter margins. Does this mean the situation is hopeless? As it stands, the problem seems to persist under both Linux and OpenBSD, which seems to indicate that neither kernel can complete the xhci initialitation. More information here: https://codeberg.org/libreboot/lbmk/issues/120 And here (please read the whole thread): https://marc.info/?t=151482563500001&r=1&w=2 Thank you! ---------------------------------------- Bug #175: Most USB3 external disk enclosures do not work with coreboot on X230 https://ticket.coreboot.org/issues/175#change-1656 * Author: Tobis Greer * Status: New * Priority: Normal * Start date: 2018-10-16 ---------------------------------------- I would like to report issues with USB3 external disk enclosures and coreboot on the Lenovo X230. I have several enclosures, and only one works without issues: Toshiba Stor E Alu 2.5. Every other one will cause the following messages in dmesg over USB3 (USB2 is fine): ``` [ 73.788819] usb 4-2: new SuperSpeed USB device number 3 using xhci_hcd [ 73.809949] usb 4-2: New USB device found, idVendor=0080, idProduct=a001 [ 73.809955] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 73.809958] usb 4-2: Product: External USB 3.0 [ 73.809961] usb 4-2: Manufacturer: TOSHIBA [ 73.809964] usb 4-2: SerialNumber: 201503310007F [ 73.813049] scsi host8: uas [ 73.813861] scsi 8:0:0:0: Direct-Access TO Exter nal USB 3.0 0204 PQ: 0 ANSI: 6 [ 73.814609] sd 8:0:0:0: Attached scsi generic sg4 type 0 [ 73.815157] sd 8:0:0:0: [sde] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) [ 73.815161] sd 8:0:0:0: [sde] 4096-byte physical blocks [ 73.815326] sd 8:0:0:0: [sde] Write Protect is off [ 73.815330] sd 8:0:0:0: [sde] Mode Sense: 53 00 00 08 [ 73.815659] sd 8:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 73.819382] sde: sde1 [ 73.820711] sd 8:0:0:0: [sde] Attached SCSI disk [ 105.329243] sd 8:0:0:0: [sde] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN [ 105.329252] sd 8:0:0:0: [sde] tag#3 CDB: Read(10) 28 00 00 00 00 80 00 01 80 00 [ 105.329334] sd 8:0:0:0: [sde] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN [ 105.329342] sd 8:0:0:0: [sde] tag#2 CDB: Read(10) 28 00 00 00 00 40 00 00 38 00 [ 105.345200] scsi host8: uas_eh_device_reset_handler start [ 105.345276] usb 4-2: cmd cmplt err -2 [ 105.473565] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 105.495210] scsi host8: uas_eh_device_reset_handler success [ 138.096012] sd 8:0:0:0: [sde] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN [ 138.096016] sd 8:0:0:0: [sde] tag#5 CDB: Read(10) 28 00 09 50 f5 d8 00 00 28 00 [ 138.096184] sd 8:0:0:0: [sde] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN [ 138.096187] sd 8:0:0:0: [sde] tag#4 CDB: Read(10) 28 00 09 50 f5 28 00 00 a8 00 [ 138.116005] scsi host8: uas_eh_device_reset_handler start [ 138.116027] usb 4-2: cmd cmplt err -2 [ 138.244231] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 138.265440] scsi host8: uas_eh_device_reset_handler success [ 168.816132] sd 8:0:0:0: [sde] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN [ 168.816138] sd 8:0:0:0: [sde] tag#4 CDB: Read(10) 28 00 09 50 f7 b8 00 00 48 00 [ 168.816174] sd 8:0:0:0: [sde] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN [ 168.816177] sd 8:0:0:0: [sde] tag#3 CDB: Read(10) 28 00 09 50 f7 28 00 00 80 00 [ 168.816208] sd 8:0:0:0: [sde] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN [ 168.816212] sd 8:0:0:0: [sde] tag#2 CDB: Read(10) 28 00 09 50 f6 68 00 00 b8 00 [ 168.832129] scsi host8: uas_eh_device_reset_handler start [ 168.832153] usb 4-2: cmd cmplt err -2 [ 168.960341] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 168.981496] scsi host8: uas_eh_device_reset_handler success [ 201.583792] sd 8:0:0:0: [sde] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 201.583796] sd 8:0:0:0: [sde] tag#0 CDB: Read(10) 28 00 00 00 10 00 00 00 08 00 [ 201.599793] scsi host8: uas_eh_device_reset_handler start [ 201.599817] usb 4-2: cmd cmplt err -2 [ 201.728046] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 201.749283] scsi host8: uas_eh_device_reset_handler success [ 234.351266] sd 8:0:0:0: [sde] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN [ 234.351270] sd 8:0:0:0: [sde] tag#3 CDB: Read(10) 28 00 00 00 08 80 00 01 80 00 [ 234.351343] sd 8:0:0:0: [sde] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN [ 234.351345] sd 8:0:0:0: [sde] tag#2 CDB: Read(10) 28 00 00 00 08 40 00 00 38 00 [ 234.375267] scsi host8: uas_eh_device_reset_handler start [ 234.375319] usb 4-2: cmd cmplt err -2 [ 234.503509] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 234.524774] scsi host8: uas_eh_device_reset_handler success [ 267.118802] sd 8:0:0:0: [sde] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 267.118810] sd 8:0:0:0: [sde] tag#0 CDB: Read(10) 28 00 00 00 0a 00 00 02 00 00 [ 267.138781] scsi host8: uas_eh_device_reset_handler start [ 267.138872] usb 4-2: cmd cmplt err -2 [ 267.267064] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 267.288888] scsi host8: uas_eh_device_reset_handler success [ 297.838883] sd 8:0:0:0: [sde] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 297.838890] sd 8:0:0:0: [sde] tag#0 CDB: Read(10) 28 00 00 60 08 00 00 00 08 00 [ 297.854785] scsi host8: uas_eh_device_reset_handler start [ 297.854827] usb 4-2: cmd cmplt err -2 [ 297.983104] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 298.004091] scsi host8: uas_eh_device_reset_handler success ``` Note that it says it's a Toshiba enclosure but it's not the Stor E Alu 2.5, it's from an Orico 2588US3-V1-BK-PRO with a 2.5" Intel X25M SSD in it. If I use Lenovo's BIOS, then I don't have any errors at all in dmesg, and I'm able to use the disk normally. With coreboot, I can't mount the disk at all and dmesg gets these error messages continuously. ---Files-------------------------------- .config (22.5 KB) lenovo_inteltool.txt (117 KB) cb_inteltool.txt (171 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

Jenkins V-1 failure due to internal error
by Compostella, Jeremy 06 Sep '23

06 Sep '23

Hi, It happened to me a couple of times in the past and again today. I got a V-1 on <https://review.coreboot.org/c/coreboot/+/77560> without any "good reasons" as <https://qa.coreboot.org/job/coreboot-gerrit/244243/console> error seems to be unrelated to my patch. Is there a way to restart the build and get rid of the V-1 without re-submitting a patch with a minor commit message change ? Regards, -- *Jeremy* /One Emacs to rule them all/

2 1

[RFC] x86: Add .data section support for XIP pre-RAM stages
by Compostella, Jeremy 06 Sep '23

06 Sep '23

Dear coreboot community, I am looking for feedback on the following topic. x86 Pre-memory stages do not support the `.data' section and as a result developers are required to include runtime initialization code instead of relying on C global variable definition. To illustrate the impact of this lack of .data section support, here are two limitations I personally ran into: 1. The inclusion of libgfxinit in romstage last year has required some changes in libgfxinit to ensure data is initialized at runtime. In addition, we had to manually map some .data symbols in the _bss region. 2. CBFS cache is currently not supported in pre-memory stages and enabling it would require to add an initialization function and find a generic spot to call it. Instead of going though these workarounds and as it was suggested on [[RFC] VGA Text mode in romstage] last year, I believe we could add support for a `.data' section. I have been working on a solution for eXecute-In-Place (XIP) pre-memory stages (`bootblock', `verstage' and `romstage') which deliver good results (cf. <https://review.coreboot.org/c/coreboot/+/77289>). In short this patch: 1. creates a new ELF segment to hold the `.data' section 2. creates a `.data' section with its Virtual Memory Address (VMA) within Cache-as-RAM (CAR) boundaries and its Load Memory Address (LMA) following the .text section (at `_etext'). cbfstools is also updated: - To process this new segment and `.data' section - To place the .data section content right after the code (cf. `parse_elf_to_xip_stage' function) At the moment, this patch makes cbfstool detects the presence of the segment automatically and assume this is a "data" segment. But we could add a new parameter to make this new behavior less automatic if you think this would be better. This patch also adds a piece of assembly code (or C-code for bootblock) to copy the `.data' section content to Cache-As-RAM at runtime. Regards, -- *Jeremy* /One Emacs to rule them all/ [[RFC] VGA Text mode in romstage] <https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2DYB…>

2 2

[PATCH v3 1/2] x86: coreboot: Update cbmem table
by Simon Glass 04 Sep '23

04 Sep '23

This changed a few years ago to include an overflow flag. Bring in the new structure. This comes from coreboot commit: 6f5ead14b4 ("mb/google/nissa/var/joxer: Update eMMC DLL settings") Note: There are several implementations of this in coreboot. I have chosen to follow the one in src/lib/cbmem_console.c Signed-off-by: Simon Glass <sjg(a)chromium.org> --- Changes in v3: - Drop __packed as it does nothing useful arch/x86/include/asm/coreboot_tables.h | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/coreboot_tables.h b/arch/x86/include/asm/coreboot_tables.h index 4de137fbab9d..0dfb64babb96 100644 --- a/arch/x86/include/asm/coreboot_tables.h +++ b/arch/x86/include/asm/coreboot_tables.h @@ -299,11 +299,24 @@ struct cb_vdat { #define CB_TAG_TIMESTAMPS 0x0016 #define CB_TAG_CBMEM_CONSOLE 0x0017 +#define CBMC_CURSOR_MASK ((1 << 28) - 1) +#define CBMC_OVERFLOW BIT(31) + +/* + * struct cbmem_console - In-memory console buffer for coreboot + * + * Structure describing console buffer. It is overlaid on a flat memory area, + * with body covering the extent of the memory. Once the buffer is full, + * output will wrap back around to the start of the buffer. The high bit of the + * cursor field gets set to indicate that this happened. If the underlying + * storage allows this, the buffer will persist across multiple boots and append + * to the previous log. + */ struct cbmem_console { u32 size; u32 cursor; - char body[0]; -} __packed; + u8 body[0]; +}; #define CB_TAG_MRC_CACHE 0x0018 -- 2.41.0.694.ge786442a9b-goog

2 3

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

01 Sep '23

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 15 new defect(s) introduced to coreboot found with Coverity Scan. 4 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 15 of 15 defect(s) ** CID 1518916: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 164 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518916: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 164 in fill_fsps_pse_params() 158 159 /* Configure PSE peripherals */ 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); >>> CID 1518916: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseHsuartEnable" of 4 bytes by passing it to a function which accesses it at byte offset 15 using argument "16UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); ** CID 1518915: (TAINTED_SCALAR) /src/soc/qualcomm/common/qupv3_config.c: 155 in qupv3_se_fw_load_and_init() /src/soc/qualcomm/common/qupv3_config.c: 83 in qupv3_se_fw_load_and_init() /src/soc/qualcomm/common/qupv3_config.c: 86 in qupv3_se_fw_load_and_init() ________________________________________________________________________________________________________ *** CID 1518915: (TAINTED_SCALAR) /src/soc/qualcomm/common/qupv3_config.c: 155 in qupv3_se_fw_load_and_init() 149 (hdr->fw_version & 0xFF << 150 FW_REV_VERSION_SHFT); 151 write32(&regs->se_s_fw_revision, reg_value); 152 153 assert(hdr->fw_size_in_items <= SIZE_GENI_FW_RAM); 154 >>> CID 1518915: (TAINTED_SCALAR) >>> Passing tainted expression "hdr->fw_size_in_items * 4UL" to "memcpy", which uses it as an offset. [Note: The source code implementation of the function has been overridden by a builtin model.] 155 memcpy((&regs->se_geni_cfg_ramn), fw_val_arr, 156 hdr->fw_size_in_items * sizeof(uint32_t)); 157 158 /* HPG section 3.1.7.12 */ 159 write32(&regs->geni_force_default_reg, 0x1); 160 setbits_le32(&regs->geni_cgc_ctrl, GENI_CGC_CTRL_PROG_RAM_SCLK_OFF_BMSK /src/soc/qualcomm/common/qupv3_config.c: 83 in qupv3_se_fw_load_and_init() 77 write32(&regs->geni_cgc_ctrl, DEFAULT_CGC_EN); 78 79 /* HPG section 3.1.7.4 */ 80 write32(&regs->geni_init_cfg_revision, hdr->cfg_version); 81 write32(&regs->geni_s_init_cfg_revision, hdr->cfg_version); 82 >>> CID 1518915: (TAINTED_SCALAR) >>> Using tainted variable "hdr->cfg_size_in_items - 1" as an index to pointer "cfg_idx_arr". 83 assert(cfg_idx_arr[hdr->cfg_size_in_items - 1] * sizeof(uint32_t) <= 84 MAX_OFFSET_CFG_REG); 85 86 for (i = 0; i < hdr->cfg_size_in_items; i++) 87 write32(&regs->geni_cfg_reg0 + cfg_idx_arr[i], 88 cfg_val_arr[i]); /src/soc/qualcomm/common/qupv3_config.c: 86 in qupv3_se_fw_load_and_init() 80 write32(&regs->geni_init_cfg_revision, hdr->cfg_version); 81 write32(&regs->geni_s_init_cfg_revision, hdr->cfg_version); 82 83 assert(cfg_idx_arr[hdr->cfg_size_in_items - 1] * sizeof(uint32_t) <= 84 MAX_OFFSET_CFG_REG); 85 >>> CID 1518915: (TAINTED_SCALAR) >>> Using tainted variable "hdr->cfg_size_in_items" as a loop boundary. 86 for (i = 0; i < hdr->cfg_size_in_items; i++) 87 write32(&regs->geni_cfg_reg0 + cfg_idx_arr[i], 88 cfg_val_arr[i]); 89 90 /* HPG section 3.1.7.9 */ 91 /* non-UART configuration, UART driver can configure as desired for UART ** CID 1518914: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 160 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518914: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 160 in fill_fsps_pse_params() 154 pse_fw_base = (uintptr_t)&psefwbuf; 155 params->SiipRegionBase = pse_fw_base; 156 params->SiipRegionSize = psefwsize; 157 printk(BIOS_DEBUG, "PSE base: %08x size: %08zx\n", pse_fw_base, psefwsize); 158 159 /* Configure PSE peripherals */ >>> CID 1518914: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseDmaEnable" of 3 bytes by passing it to a function which accesses it at byte offset 11 using argument "12UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); ** CID 1518913: (TAINTED_SCALAR) /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() ________________________________________________________________________________________________________ *** CID 1518913: (TAINTED_SCALAR) /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() 219 ext_tbl = ucode_get_ext_sig_table(ucode_updates); 220 221 if (ext_tbl != NULL) { 222 int i; 223 struct ext_sig_entry *entry = (struct ext_sig_entry *)(ext_tbl + 1); 224 >>> CID 1518913: (TAINTED_SCALAR) >>> Using tainted variable "ext_tbl->ext_sig_cnt" as a loop boundary. 225 for (i = 0; i < ext_tbl->ext_sig_cnt; i++, entry++) { 226 if ((sig == entry->sig) && (pf & entry->pf)) { 227 return ucode_updates; 228 } 229 } 230 } /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() 219 ext_tbl = ucode_get_ext_sig_table(ucode_updates); 220 221 if (ext_tbl != NULL) { 222 int i; 223 struct ext_sig_entry *entry = (struct ext_sig_entry *)(ext_tbl + 1); 224 >>> CID 1518913: (TAINTED_SCALAR) >>> Using tainted variable "ext_tbl->ext_sig_cnt" as a loop boundary. 225 for (i = 0; i < ext_tbl->ext_sig_cnt; i++, entry++) { 226 if ((sig == entry->sig) && (pf & entry->pf)) { 227 return ucode_updates; 228 } 229 } 230 } /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() 219 ext_tbl = ucode_get_ext_sig_table(ucode_updates); 220 221 if (ext_tbl != NULL) { 222 int i; 223 struct ext_sig_entry *entry = (struct ext_sig_entry *)(ext_tbl + 1); 224 >>> CID 1518913: (TAINTED_SCALAR) >>> Using tainted variable "ext_tbl->ext_sig_cnt" as a loop boundary. 225 for (i = 0; i < ext_tbl->ext_sig_cnt; i++, entry++) { 226 if ((sig == entry->sig) && (pf & entry->pf)) { 227 return ucode_updates; 228 } 229 } 230 } /src/cpu/intel/microcode/microcode.c: 225 in find_cbfs_microcode() 219 ext_tbl = ucode_get_ext_sig_table(ucode_updates); 220 221 if (ext_tbl != NULL) { 222 int i; 223 struct ext_sig_entry *entry = (struct ext_sig_entry *)(ext_tbl + 1); 224 >>> CID 1518913: (TAINTED_SCALAR) >>> Using tainted variable "ext_tbl->ext_sig_cnt" as a loop boundary. 225 for (i = 0; i < ext_tbl->ext_sig_cnt; i++, entry++) { 226 if ((sig == entry->sig) && (pf & entry->pf)) { 227 return ucode_updates; 228 } 229 } 230 } ** CID 1518912: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 165 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518912: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 165 in fill_fsps_pse_params() 159 /* Configure PSE peripherals */ 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); >>> CID 1518912: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseQepEnable" of 4 bytes by passing it to a function which accesses it at byte offset 15 using argument "16UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); ** CID 1518911: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 175 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518911: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 175 in fill_fsps_pse_params() 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); >>> CID 1518911: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseCanEnable" of 2 bytes by passing it to a function which accesses it at byte offset 7 using argument "8UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); 177 params->PchPsePwmEnable = config->PsePwmOwn; 178 params->PchPsePwmSbInterruptEnable = config->PsePwmSbIntEn; 179 FSP_ARRAY_LOAD(params->PchPsePwmPinEnable, config->PsePwmPinEn); 180 params->PchPseAdcEnable = config->PseAdcOwn; ** CID 1518910: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 174 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518910: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 174 in fill_fsps_pse_params() 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); >>> CID 1518910: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseSpiCs1Enable" of 4 bytes by passing it to a function which accesses it at byte offset 15 using argument "16UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); 177 params->PchPsePwmEnable = config->PsePwmOwn; 178 params->PchPsePwmSbInterruptEnable = config->PsePwmSbIntEn; 179 FSP_ARRAY_LOAD(params->PchPsePwmPinEnable, config->PsePwmPinEn); ** CID 1518909: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 169 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518909: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 169 in fill_fsps_pse_params() 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); >>> CID 1518909: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseI2sEnable" of 2 bytes by passing it to a function which accesses it at byte offset 7 using argument "8UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); ** CID 1518908: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 167 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518908: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 167 in fill_fsps_pse_params() 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); >>> CID 1518908: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseI2cEnable" of 8 bytes by passing it to a function which accesses it at byte offset 31 using argument "32UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); ** CID 1518907: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1518907: Null pointer dereferences (FORWARD_NULL) /src/acpi/acpi.c: 1499 in write_acpi_tables() 1493 current = acpi_align_current(current); 1494 1495 /* clear all table memory */ 1496 memset((void *)start, 0, current - start); 1497 1498 acpi_write_rsdp(rsdp, rsdt, xsdt, oem_id); >>> CID 1518907: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "rsdt" to "acpi_write_rsdt", which dereferences it. 1499 acpi_write_rsdt(rsdt, oem_id, oem_table_id); 1500 acpi_write_xsdt(xsdt, oem_id, oem_table_id); 1501 1502 if (ENV_X86) { 1503 printk(BIOS_DEBUG, "ACPI: * FACS\n"); 1504 current = ALIGN_UP(current, 64); ** CID 1518906: (BUFFER_SIZE) /src/soc/intel/elkhartlake/fsp_params.c: 164 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 160 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 167 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 171 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 173 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 169 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 165 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 175 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 174 in fill_fsps_pse_params() /src/soc/intel/elkhartlake/fsp_params.c: 162 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518906: (BUFFER_SIZE) /src/soc/intel/elkhartlake/fsp_params.c: 164 in fill_fsps_pse_params() 158 159 /* Configure PSE peripherals */ 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 4 byte destination string "params->PchPseHsuartEnable" by writing the maximum 16 bytes from "config->PseHsuartOwn". 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); /src/soc/intel/elkhartlake/fsp_params.c: 160 in fill_fsps_pse_params() 154 pse_fw_base = (uintptr_t)&psefwbuf; 155 params->SiipRegionBase = pse_fw_base; 156 params->SiipRegionSize = psefwsize; 157 printk(BIOS_DEBUG, "PSE base: %08x size: %08zx\n", pse_fw_base, psefwsize); 158 159 /* Configure PSE peripherals */ >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 3 byte destination string "params->PchPseDmaEnable" by writing the maximum 12 bytes from "config->PseDmaOwn". 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); /src/soc/intel/elkhartlake/fsp_params.c: 167 in fill_fsps_pse_params() 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 8 byte destination string "params->PchPseI2cEnable" by writing the maximum 32 bytes from "config->PseI2cOwn". 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); /src/soc/intel/elkhartlake/fsp_params.c: 171 in fill_fsps_pse_params() 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 4 byte destination string "params->PchPseSpiEnable" by writing the maximum 16 bytes from "config->PseSpiOwn". 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); /src/soc/intel/elkhartlake/fsp_params.c: 173 in fill_fsps_pse_params() 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 4 byte destination string "params->PchPseSpiCs0Enable" by writing the maximum 16 bytes from "config->PseSpiCs0Own". 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); 177 params->PchPsePwmEnable = config->PsePwmOwn; 178 params->PchPsePwmSbInterruptEnable = config->PsePwmSbIntEn; /src/soc/intel/elkhartlake/fsp_params.c: 169 in fill_fsps_pse_params() 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 2 byte destination string "params->PchPseI2sEnable" by writing the maximum 8 bytes from "config->PseI2sOwn". 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); /src/soc/intel/elkhartlake/fsp_params.c: 165 in fill_fsps_pse_params() 159 /* Configure PSE peripherals */ 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 4 byte destination string "params->PchPseQepEnable" by writing the maximum 16 bytes from "config->PseQepOwn". 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); /src/soc/intel/elkhartlake/fsp_params.c: 175 in fill_fsps_pse_params() 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 2 byte destination string "params->PchPseCanEnable" by writing the maximum 8 bytes from "config->PseCanOwn". 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); 177 params->PchPsePwmEnable = config->PsePwmOwn; 178 params->PchPsePwmSbInterruptEnable = config->PsePwmSbIntEn; 179 FSP_ARRAY_LOAD(params->PchPsePwmPinEnable, config->PsePwmPinEn); 180 params->PchPseAdcEnable = config->PseAdcOwn; /src/soc/intel/elkhartlake/fsp_params.c: 174 in fill_fsps_pse_params() 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 4 byte destination string "params->PchPseSpiCs1Enable" by writing the maximum 16 bytes from "config->PseSpiCs1Own". 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); 177 params->PchPsePwmEnable = config->PsePwmOwn; 178 params->PchPsePwmSbInterruptEnable = config->PsePwmSbIntEn; 179 FSP_ARRAY_LOAD(params->PchPsePwmPinEnable, config->PsePwmPinEn); /src/soc/intel/elkhartlake/fsp_params.c: 162 in fill_fsps_pse_params() 156 params->SiipRegionSize = psefwsize; 157 printk(BIOS_DEBUG, "PSE base: %08x size: %08zx\n", pse_fw_base, psefwsize); 158 159 /* Configure PSE peripherals */ 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); >>> CID 1518906: (BUFFER_SIZE) >>> You might overrun the 6 byte destination string "params->PchPseUartEnable" by writing the maximum 24 bytes from "config->PseUartOwn". 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); ** CID 1518905: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 171 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518905: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 171 in fill_fsps_pse_params() 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); >>> CID 1518905: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseSpiEnable" of 4 bytes by passing it to a function which accesses it at byte offset 15 using argument "16UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); ** CID 1518904: Integer handling issues (BAD_SHIFT) /src/security/intel/txt/common.c: 277 in intel_txt_prepare_bios_acm() ________________________________________________________________________________________________________ *** CID 1518904: Integer handling issues (BAD_SHIFT) /src/security/intel/txt/common.c: 277 in intel_txt_prepare_bios_acm() 271 } 272 273 /* 274 * The ACM should be aligned to it's size, but that's not possible, as 275 * some ACMs are not power of two. Use the next power of two for verification. 276 */ >>> CID 1518904: Integer handling issues (BAD_SHIFT) >>> In expression "1UL << log2_ceil(*acm_len)", shifting by a negative amount has undefined behavior. The shift amount, "log2_ceil(*acm_len)", is -1. 277 if (!IS_ALIGNED((uintptr_t)acm_data, (1UL << log2_ceil(*acm_len)))) { 278 printk(BIOS_ERR, "TEE-TXT: BIOS ACM isn't aligned to its size.\n"); 279 cbfs_unmap(acm_data); 280 return NULL; 281 } 282 ** CID 1518903: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 162 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518903: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 162 in fill_fsps_pse_params() 156 params->SiipRegionSize = psefwsize; 157 printk(BIOS_DEBUG, "PSE base: %08x size: %08zx\n", pse_fw_base, psefwsize); 158 159 /* Configure PSE peripherals */ 160 FSP_ARRAY_LOAD(params->PchPseDmaEnable, config->PseDmaOwn); 161 FSP_ARRAY_LOAD(params->PchPseDmaSbInterruptEnable, config->PseDmaSbIntEn); >>> CID 1518903: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseUartEnable" of 6 bytes by passing it to a function which accesses it at byte offset 23 using argument "24UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 162 FSP_ARRAY_LOAD(params->PchPseUartEnable, config->PseUartOwn); 163 FSP_ARRAY_LOAD(params->PchPseUartSbInterruptEnable, config->PseUartSbIntEn); 164 FSP_ARRAY_LOAD(params->PchPseHsuartEnable, config->PseHsuartOwn); 165 FSP_ARRAY_LOAD(params->PchPseQepEnable, config->PseQepOwn); 166 FSP_ARRAY_LOAD(params->PchPseQepSbInterruptEnable, config->PseQepSbIntEn); 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); ** CID 1518902: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 173 in fill_fsps_pse_params() ________________________________________________________________________________________________________ *** CID 1518902: Memory - corruptions (OVERRUN) /src/soc/intel/elkhartlake/fsp_params.c: 173 in fill_fsps_pse_params() 167 FSP_ARRAY_LOAD(params->PchPseI2cEnable, config->PseI2cOwn); 168 FSP_ARRAY_LOAD(params->PchPseI2cSbInterruptEnable, config->PseI2cSbIntEn); 169 FSP_ARRAY_LOAD(params->PchPseI2sEnable, config->PseI2sOwn); 170 FSP_ARRAY_LOAD(params->PchPseI2sSbInterruptEnable, config->PseI2sSbIntEn); 171 FSP_ARRAY_LOAD(params->PchPseSpiEnable, config->PseSpiOwn); 172 FSP_ARRAY_LOAD(params->PchPseSpiSbInterruptEnable, config->PseSpiSbIntEn); >>> CID 1518902: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PchPseSpiCs0Enable" of 4 bytes by passing it to a function which accesses it at byte offset 15 using argument "16UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 173 FSP_ARRAY_LOAD(params->PchPseSpiCs0Enable, config->PseSpiCs0Own); 174 FSP_ARRAY_LOAD(params->PchPseSpiCs1Enable, config->PseSpiCs1Own); 175 FSP_ARRAY_LOAD(params->PchPseCanEnable, config->PseCanOwn); 176 FSP_ARRAY_LOAD(params->PchPseCanSbInterruptEnable, config->PseCanSbIntEn); 177 params->PchPsePwmEnable = config->PsePwmOwn; 178 params->PchPsePwmSbInterruptEnable = config->PsePwmSbIntEn; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

[coreboot - Bug #499] (New) coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build
by Oberon 4071 31 Aug '23

31 Aug '23

Issue #499 has been reported by Oberon 4071. ---------------------------------------- Bug #499: coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build https://ticket.coreboot.org/issues/499 * Author: Oberon 4071 * Status: New * Priority: Normal * Category: coreboot common code * Start date: 2023-06-29 * Affected versions: 4.21 * Needs backport to: none * Affected hardware: lenovo/t440p ---------------------------------------- coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3 Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and uefipayload_202306 coreboot will not boot my Lenovo ThinkPad T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload (MrChromebox version, either uefipayload_202304 or uefipayload_202306). The display sometimes turns on, indicating that some of the hardware initialization was successful, but the payload will not start. I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the build process insists on leaving this config enabled. This seems to be caused by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451 (allocator_v4: Treat above 4G resources more natively). The make target for building coreboot seems to automatically rerun olddefconfig, causing this setting to always remain enabled no matter what was previously saved in the .config file. Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to "def_bool n" appears to fix the problem on my machine. I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled to reproduce the problem). ---Files-------------------------------- .config (20.7 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

6 25

New on blogs.coreboot.org: coreboot version 4.21 released
by blogs.coreboot.org 30 Aug '23

30 Aug '23

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