coreboot

coreboot@coreboot.org

17 participants
39654 discussions

Guidelines for using die()
by Martin Roth 14 Dec '22

14 Dec '22

I'd like to propose that we set up a guideline for when coreboot should use die(). My belief, and proposal for the guideline is that coreboot should *ONLY* die in 2 situations: 1) The system cannot continue booting. Examples: * coreboot needs to jump somewhere to continue, but doesn’t have a location to jump to. * The system needs to reset to continue, but reset failed or isn’t implemented. * Memory init failed. (SPD can't be read, Failed to initialize memory controller, etc.) 2) There’s a known security issue if booting continues. Even this shouldn’t be a hard die(), because there should still be a manual process to boot the system so that the firmware can be updated. (we can work that out later) Examples: * HASH table verification failed! * Can't verify flash protections! It looks like most die() calls are valid, but there are currently cases where coreboot dies for a “non-fatal” reason. The case I’m currently looking at is when running an FSP, and the FSP ID is not the expected ID. https://review.coreboot.org/c/coreboot/+/69412 My opinion is that coreboot should put out a warning, but jump to the FSP anyway. If it fails, it’s the FSP’s responsibility to return a failure code to coreboot to die. (More likely, it would die internally without returning, which is no worse than coreboot dying. coreboot has no idea what the FSP is going to do and isn’t responsible for it. This is a case of “there looks like there’s a problem, proceed with caution”, but is being treated as a situation where coreboot cannot continue. Other examples where maybe we shouldn’t be dying: * die("EHCI controller (00:1a.7) not listed in devicetree.\n"); We don’t need the EHCI controller to boot, at least not at this point. * die("RAM init: Decoded SPD DRAM freq is slower than the controller minimum!"); So try with the controller minimum and die if that fails. * die("Onboard SPDs must match each other"); Pick an SPD and try initializing memory with it. Die if that fails. * die("IGD is disabled!"); So try to boot without graphics… * die("Invalid GPIO pad number\n"); So put out a warning and skip the GPIO. An assert would be reasonable - a hard die() isn’t, in my opinion. * die("BUG: Increase ehci_dbg_info reserve in CAR"); Use an assert, bail out of ehci_dbg. coreboot doesn't even make ASSERT fatal by default because we don't have a good way to communicate errors to the user. This proposal aligns with that. I've added this topic to the leadership meeting minutes for tomorrow. Let me know what you think. Thanks! Martin

5 4

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

13 Dec '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 new defect(s) introduced to coreboot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1501510: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/commonlib/bsd/include/commonlib/bsd/mem_chip_info.h: 104 in mem_chip_info_total_density_bytes() ________________________________________________________________________________________________________ *** CID 1501510: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/commonlib/bsd/include/commonlib/bsd/mem_chip_info.h: 104 in mem_chip_info_total_density_bytes() 98 { 99 uint64_t bytes = 0; 100 int i; 101 102 for (i = 0; i < info->num_entries; i++) { 103 const struct mem_chip_entry *e = &info->entries[i]; >>> CID 1501510: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "e->density_mbits * (e->channel_io_width / e->io_width)" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 104 bytes += e->density_mbits * (e->channel_io_width / e->io_width) * (MiB / 8); 105 } 106 107 return bytes; 108 } 109 ** CID 1501509: (CONSTANT_EXPRESSION_RESULT) /src/soc/amd/cezanne/fsp_m_params.c: 160 in platform_fsp_memory_init_params_cb() /src/soc/amd/morgana/fsp_m_params.c: 162 in platform_fsp_memory_init_params_cb() /src/soc/amd/mendocino/fsp_m_params.c: 161 in platform_fsp_memory_init_params_cb() /src/soc/amd/glinda/fsp_m_params.c: 162 in platform_fsp_memory_init_params_cb() ________________________________________________________________________________________________________ *** CID 1501509: (CONSTANT_EXPRESSION_RESULT) /src/soc/amd/cezanne/fsp_m_params.c: 160 in platform_fsp_memory_init_params_cb() 154 /* devicetree config is const, use local copy */ 155 static struct usb_phy_config lcl_usb_phy; 156 lcl_usb_phy = config->usb_phy; 157 lcl_usb_phy.Version_Major = FSP_USB_STRUCT_MAJOR_VERSION; 158 lcl_usb_phy.Version_Minor = FSP_USB_STRUCT_MINOR_VERSION; 159 lcl_usb_phy.TableLength = sizeof(struct usb_phy_config); >>> CID 1501509: (CONSTANT_EXPRESSION_RESULT) >>> "(uintptr_t)&lcl_usb_phy <= 4294967295UL /* (uint32_t)4294967295U */" is always true regardless of the values of its operands. This occurs as the logical operand of "if". 160 if ((uintptr_t)&lcl_usb_phy <= UINT32_MAX) { 161 mcfg->usb_phy_ptr = (uint32_t)(uintptr_t)&lcl_usb_phy; 162 } else { 163 printk(BIOS_ERR, "USB PHY config struct above 4GB; can't pass USB PHY " 164 "configuration to 32 bit FSP.\n"); 165 mcfg->usb_phy_ptr = 0; /src/soc/amd/morgana/fsp_m_params.c: 162 in platform_fsp_memory_init_params_cb() 156 /* devicetree config is const, use local copy */ 157 static struct usb_phy_config lcl_usb_phy; 158 lcl_usb_phy = config->usb_phy; 159 lcl_usb_phy.Version_Major = FSP_USB_STRUCT_MAJOR_VERSION; 160 lcl_usb_phy.Version_Minor = FSP_USB_STRUCT_MINOR_VERSION; 161 lcl_usb_phy.TableLength = sizeof(struct usb_phy_config); >>> CID 1501509: (CONSTANT_EXPRESSION_RESULT) >>> "(uintptr_t)&lcl_usb_phy <= 4294967295UL /* (uint32_t)4294967295U */" is always true regardless of the values of its operands. This occurs as the logical operand of "if". 162 if ((uintptr_t)&lcl_usb_phy <= UINT32_MAX) { 163 mcfg->usb_phy_ptr = (uint32_t)(uintptr_t)&lcl_usb_phy; 164 } else { 165 printk(BIOS_ERR, "USB PHY config struct above 4GB; can't pass USB PHY " 166 "configuration to 32 bit FSP.\n"); 167 mcfg->usb_phy_ptr = 0; /src/soc/amd/mendocino/fsp_m_params.c: 161 in platform_fsp_memory_init_params_cb() 155 /* devicetree config is const, use local copy */ 156 static struct usb_phy_config lcl_usb_phy; 157 lcl_usb_phy = config->usb_phy; 158 lcl_usb_phy.Version_Major = FSP_USB_STRUCT_MAJOR_VERSION; 159 lcl_usb_phy.Version_Minor = FSP_USB_STRUCT_MINOR_VERSION; 160 lcl_usb_phy.TableLength = sizeof(struct usb_phy_config); >>> CID 1501509: (CONSTANT_EXPRESSION_RESULT) >>> "(uintptr_t)&lcl_usb_phy <= 4294967295UL /* (uint32_t)4294967295U */" is always true regardless of the values of its operands. This occurs as the logical operand of "if". 161 if ((uintptr_t)&lcl_usb_phy <= UINT32_MAX) { 162 mcfg->usb_phy_ptr = (uint32_t)(uintptr_t)&lcl_usb_phy; 163 } else { 164 printk(BIOS_ERR, "USB PHY config struct above 4GB; can't pass USB PHY " 165 "configuration to 32 bit FSP.\n"); 166 mcfg->usb_phy_ptr = 0; /src/soc/amd/glinda/fsp_m_params.c: 162 in platform_fsp_memory_init_params_cb() 156 /* devicetree config is const, use local copy */ 157 static struct usb_phy_config lcl_usb_phy; 158 lcl_usb_phy = config->usb_phy; 159 lcl_usb_phy.Version_Major = FSP_USB_STRUCT_MAJOR_VERSION; 160 lcl_usb_phy.Version_Minor = FSP_USB_STRUCT_MINOR_VERSION; 161 lcl_usb_phy.TableLength = sizeof(struct usb_phy_config); >>> CID 1501509: (CONSTANT_EXPRESSION_RESULT) >>> "(uintptr_t)&lcl_usb_phy <= 4294967295UL /* (uint32_t)4294967295U */" is always true regardless of the values of its operands. This occurs as the logical operand of "if". 162 if ((uintptr_t)&lcl_usb_phy <= UINT32_MAX) { 163 mcfg->usb_phy_ptr = (uint32_t)(uintptr_t)&lcl_usb_phy; 164 } else { 165 printk(BIOS_ERR, "USB PHY config struct above 4GB; can't pass USB PHY " 166 "configuration to 32 bit FSP.\n"); 167 mcfg->usb_phy_ptr = 0; ** CID 1501508: Null pointer dereferences (FORWARD_NULL) /src/drivers/intel/fsp2_0/memory_init.c: 61 in do_fsp_post_memory_init() ________________________________________________________________________________________________________ *** CID 1501508: Null pointer dereferences (FORWARD_NULL) /src/drivers/intel/fsp2_0/memory_init.c: 61 in do_fsp_post_memory_init() 55 /* ramstage uses the FSP-M version when updating the MRC cache */ 56 if (CONFIG(CACHE_MRC_SETTINGS) && !s3wake) { 57 fsp_version_cbmem = cbmem_add(CBMEM_ID_FSPM_VERSION, 58 sizeof(fsp_version)); 59 if (!fsp_version_cbmem) 60 printk(BIOS_ERR, "Failed to add FSP-M version to cbmem.\n"); >>> CID 1501508: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "fsp_version_cbmem". 61 *fsp_version_cbmem = fsp_version; 62 } 63 64 /* Create romstage handof information */ 65 romstage_handoff_init(s3wake); 66 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

FOSDEM23 Open Source Firmware, BMC and Bootloader Devroom CFP - last call
by Michał Żygowski 12 Dec '22

12 Dec '22

Hi all, Just a reminder that FOSDEM23 Open Source Firmware, BMC and Bootloader Devroom CfP ends today. If you have any coreboot topics you would like to present, feel free to send a submission: https://lists.fosdem.org/pipermail/fosdem/2022q4/003467.html Best regards, -- Michał Żygowski Firmware Engineer GPG: 6B5BA214D21FCEB2 https://3mdeb.com | @3mdeb_com

1 0

Joining the mailing list, also NUC?
by Mac Wynkoop 04 Dec '22

04 Dec '22

Hello all, I see that at one point someone was able to flash Coreboot onto a 6th gen Intel NUC? Are there any instructions floating around on how to do that? Thanks all, Mac

1 0

coreboot-gerrit failures ---> rm: cannot remove '/home/coreboot/node-root/workspace/coreboot-gerrit/abuild-scanbuild.xml': No such file or directory
by Mike Banon 04 Dec '22

04 Dec '22

Good day! Unfortunately, a lot of builds are failing with this error, and it would be nice if you could fix this soon. -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 1

[RFC] VGA Text mode in romstage
by Compostella, Jeremy 03 Dec '22

03 Dec '22

Dear coreboot developers, In order to improve the user experience we would like to display a message on the screen while memory training is in progress. As a first step, we are working on Alder Lake and Raptor Lake platforms and are leveraging the `libgfxinit' and VGA text mode. We have libgfxinit patches for Tiger Lake, Alder Lake (and Raptor Lake) support under review but this is not the object of this email (see <https://review.coreboot.org/c/libgfxinit/+/65087> if you are interested) In the last few weeks, we have been working on a proof-of-concept to ensure that we could overcome all the technical hardware challenges to initialize VGA text mode and setup the display before we jump into FSP memory. Even though we are still working on some stability issues, we have a "working" but hacky patch :-). But we have an aggressive timeline and it works good enough that we believe it is time to start an open discussion as the surface of the patch is important (linker scripts, configuration flags logic ...). The changes have been reduced to a unique patch after a lot of clean-up (<https://review.coreboot.org/c/coreboot/+/69757>). This patch will be split up in a couple of patches once we are done with some in progress development. We identified three majors "issues" for which we are seeking feedback, guidance or help. PCI resource allocation ======================= <https://review.coreboot.org/c/coreboot/+/69757/2/src/soc/intel/alderlake/ro…> We need to configure the graphics PCI device to perform graphic initialization. It requires to perform an early romstage PCI resource allocation. For the proof-of-concept, we assigned the same resources than the coreboot resource allocator would assign during ramstage. We cannot leave hardcoded values like these. Any suggestion on how to cleanly handle early PCI resources allocation ? Configuration flags and "duplicated" ==================================== <https://review.coreboot.org/c/coreboot/+/69757/2/src/drivers/intel/fsp2_0/K…> <https://review.coreboot.org/c/coreboot/+/69757/2/src/lib/Kconfig> <https://review.coreboot.org/c/coreboot/+/69757/2/src/device/Kconfig> We had to "duplicate" some configuration flags such as `MAINBOARD_USE_LIBGFXINIT' as a `ROMSTAGE_MAINBOARD_USE_LIBGFXINIT' for instance. We want to separate configuration between romstage and ramstage to offer flexibility to use to have VGA text mode in romstage without any graphics initialization in ramstage or a graphic initialization with the GOP driver in ramstage ... We would appreciate some review and feedback on our clearly not perfect `Kconfig' changes. Any suggestion is welcome. libgfxinit and global initialized variables =========================================== <https://review.coreboot.org/c/coreboot/+/69757/1/src/arch/x86/car.ld> `libgfxinit' has some initialized global variables ending up in the `.data' section. Global *initialized* variables are not permitted in cache-as-ram and with the current `car.ld' linker script I hit compilation link errors due the following list of variables. Using objdump I collected their initial value (note that I did not exhaustively checked all the `[...]_E' ones but only a sample of them). Address Type Name Value ----------------------------------------------------------------------------- ffffff60 d `hw__debug__register_write_delay_nanoseconds' 00 ffffff68 d `hw__debug__start_of_line' 01 ffffff2c d `hw__gfx__gma__registers__gtt_32__range_aXnnn' 00 20 00 00 ffffff28 d `hw__gfx__gma__registers__gtt_64__range_aXnnn' 00 80 00 00 ffffff30 d `hw__gfx__gma__registers__regs__range_aXnnn' 00 00 00 00 ffffff6e D `gma_E' 00 ... ffffff70 D `gma__gfx_init_E' 00 ... ffffff6a D `hw__debug_E' 00 ... ffffff6c D `hw__debug_sink_E' 00 ... ffffff02 D `hw__gfx__dp_aux_ch_E' 00 ... ffffff04 D `hw__gfx__dp_dual_mode_E' 00 ... ffffff06 D `hw__gfx__dp_info_E' 00 ... ffffff08 D `hw__gfx__dp_training_E' 00 ... ffffff0a D `hw__gfx__edid_E' 00 ... ffffff0c D `hw__gfx__framebuffer_filler_E' 00 ... ffffff3a D `hw__gfx__gma_E' 00 ... ffffff3c D `hw__gfx__gma__combo_phy_E' 00 ... ffffff00 D `hw__gfx__gma__config_E' 00 ... ffffff0e D `hw__gfx__gma__config_helpers_E' 00 ... ffffff10 D `hw__gfx__gma__connector_info_E' 00 ... ffffff42 D `hw__gfx__gma__connectors_E' 00 ... ffffff3e D `hw__gfx__gma__connectors__combo_phy_E' 00 ... ffffff40 D `hw__gfx__gma__connectors__tc_E' 00 ... ffffff12 D `hw__gfx__gma__display_probing_E' 00 ... ffffff14 D `hw__gfx__gma__dp_aux_request_E' 00 ... ffffff16 D `hw__gfx__gma__i2c_E' 00 ... ffffff38 D `hw__gfx__gma__initialized' 00 ... ffffff18 D `hw__gfx__gma__panel_E' 00 ... ffffff1a D `hw__gfx__gma__pch__fdi_E' 00 ... ffffff1c D `hw__gfx__gma__pch__sideband_E' 00 ... ffffff1e D `hw__gfx__gma__pch__transcoder_E' 00 ... ffffff20 D `hw__gfx__gma__pch__vga_E' 00 ... ffffff22 D `hw__gfx__gma__pcode_E' 00 ... ffffff24 D `hw__gfx__gma__pipe_setup_E' 00 ... ffffff48 D `hw__gfx__gma__plls_E' 00 ... ffffff44 D `hw__gfx__gma__plls__combo_phy_E' 00 ... ffffff46 D `hw__gfx__gma__plls__dkl_E' 00 ... ffffff4a D `hw__gfx__gma__port_detect_E' 00 ... ffffff50 D `hw__gfx__gma__power_and_clocks_E' 00 ... ffffff4c D `hw__gfx__gma__power_and_clocks__tgl_E' 00 ... ffffff4e D `hw__gfx__gma__power_and_clocks__xelpd_E' 00 ... ffffff34 D `hw__gfx__gma__registers_E' 00 ... ffffff36 D `hw__gfx__gma__transcoder_E' 00 ... ffffff52 D `hw__mmio_range_E' 00 ... ffffff56 D `hw__mmio_regs_E' 00 ... ffffff54 D `hw__pci__dev_E' 00 ... ffffff58 D `hw__pci__mmconf_E' 00 ... ffffff5a D `hw__port_io_E' 00 ... ffffff5c D `hw__time_E' 00 ... ffffff72 D `hw__time__timer_E' 00 ... The symbols ending with `_E' are empty and initialized by GNAT generated code (cf. `___elabs' functions) which is called using the `$stage_adainit()' function. Therefor, I think it is safe to places these into the `_bss' region of the `.car.data' section. What I don't understand though is why isn't the GNAT compiler placing them into the `.bss' region of the object file. Any idea ? I could not find any GNAT compiler option for this but I am clearly not an ADA compiler expert :-) Now we are left with the following symbols: - `hw__debug__register_write_delay_nanoseconds' is zero so installing it in the `_bss' region of the `.car.data' section is "technically" fine. - `hw__debug__start_of_line': Reverting the logic of this boolean makes it work - The following three symbols are the most challenging ones: - `hw__gfx__gma__registers__gtt_32__range_aXnnn' - `hw__gfx__gma__registers__gtt_64__range_aXnnn' - `hw__gfx__gma__registers__regs__range_aXnnn' They seem to be entirely by the compiler and I don't know how to control them. Surprisingly, putting them in the `_bss' region of the `.car.data' section which is making them zeros is not causing any apparent issue while their initial value should not be zeros. I am thinking that these could be used for code verification purposes only. Does anyone knows before I adventure in to assembly code to uncover their role ? Regards, -- *Jeremy* /One Emacs to rule them all/

5 9

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

02 Dec '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1501187: Control flow issues (DEADCODE) /src/drivers/intel/fsp2_0/ppi/mp_service_ppi.c: 40 in mp_get_processor_info() ________________________________________________________________________________________________________ *** CID 1501187: Control flow issues (DEADCODE) /src/drivers/intel/fsp2_0/ppi/mp_service_ppi.c: 40 in mp_get_processor_info() 34 if (processor_number >= MIN(get_cpu_count(), CONFIG_MAX_CPUS)) 35 return FSP_NOT_FOUND; 36 37 extern struct cpu_info cpu_infos[]; 38 struct cpu_info *info = &cpu_infos[processor_number]; 39 if (!info) >>> CID 1501187: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 2147483655U;". 40 return FSP_DEVICE_ERROR; 41 42 if (processor_info_buffer == NULL) 43 return FSP_INVALID_PARAMETER; 44 apicid = info->cpu->path.apic.apic_id; 45 ** CID 1501186: (DEADCODE) /src/mainboard/google/herobrine/mainboard.c: 105 in mainboard_needs_pcie_init() /src/mainboard/google/herobrine/mainboard.c: 102 in mainboard_needs_pcie_init() ________________________________________________________________________________________________________ *** CID 1501186: (DEADCODE) /src/mainboard/google/herobrine/mainboard.c: 105 in mainboard_needs_pcie_init() 99 uint32_t sku = sku_id() & sku_bits_mask; 100 101 if (sku == CROS_SKU_UNKNOWN) { 102 printk(BIOS_WARNING, "Unknown SKU (%#x); assuming PCIe", sku); 103 return true; 104 } else if (sku == CROS_SKU_UNPROVISIONED) { >>> CID 1501186: (DEADCODE) >>> Execution cannot reach this statement: "printk(4, "Unprovisioned SK...". 105 printk(BIOS_WARNING, "Unprovisioned SKU (%#x); assuming PCIe", sku); 106 return true; 107 } 108 109 if ((sku % 3) == 2) 110 return true; /src/mainboard/google/herobrine/mainboard.c: 102 in mainboard_needs_pcie_init() 96 * each tristate, so we can represent numbers up to 27, or 5 bits 97 */ 98 uint32_t sku_bits_mask = 0xff; 99 uint32_t sku = sku_id() & sku_bits_mask; 100 101 if (sku == CROS_SKU_UNKNOWN) { >>> CID 1501186: (DEADCODE) >>> Execution cannot reach this statement: "printk(4, "Unknown SKU (%#x...". 102 printk(BIOS_WARNING, "Unknown SKU (%#x); assuming PCIe", sku); 103 return true; 104 } else if (sku == CROS_SKU_UNPROVISIONED) { 105 printk(BIOS_WARNING, "Unprovisioned SKU (%#x); assuming PCIe", sku); 106 return true; 107 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Regarding Google Summer of Code (Introduction)
by Sarthak Rohatgi 01 Dec '22

01 Dec '22

Greetings, I am Sarthak Rohatgi, a third year student from India. I am very much interested in Google Summer of Code (GSOC) for 2023, would you be able to guide me into it? About myself - I am Sarthak Rohatgi, currently a 3rd year student pursuing Computer Science Engineering. I am really passionate about programming and have been doing it for 4-5 years. I have worked with many different technologies and languages for example C, C++, JavaScript (NodeJS), Flutter, React, Django, GoLang, MySQL, PostgreSQL, WebRTC, WebSockets Bash and more. I did my Apprenticeship for 1 month from Microsoft and created and deployed multiple websites on the web. I also have experience in cross-platform development using Flutter Framework and have developed 3 apps which are in production. My preferred tech stack includes, C++, Flutter, GoLang and JavaScript. I have been interested in open-source for a long time but haven't had the chance to get started with it. I would love to know how I can get started with it and get selected as a GSOC Contributor as well. (Attached Below is my resume which has all the links including my GitHub, Hackerrank, Project links, Leetcode, etc.) Resume <https://sarthakrohatgi012201-dot-mindful-primer-357708.uc.r.appspot.com/?c=…> Thanks & Regards Sarthak Rohatgi [image: sarthakrohatgi012201]sarthakrohatgi012201

1 0

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

25 Nov '22

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 13 new defect(s) introduced to coreboot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 13 of 13 defect(s) ** CID 1501089: Null pointer dereferences (FORWARD_NULL) /src/ec/clevo/it5570e/ec.c: 37 in pnp_configure_smfi() ________________________________________________________________________________________________________ *** CID 1501089: Null pointer dereferences (FORWARD_NULL) /src/ec/clevo/it5570e/ec.c: 37 in pnp_configure_smfi() 31 32 struct device dev = { 33 .path.type = DEVICE_PATH_PNP, 34 .path.pnp.port = 0x2e, 35 .path.pnp.device = IT5570E_SMFI, 36 }; >>> CID 1501089: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "dev.ops". 37 dev.ops->ops_pnp_mode = &pnp_conf_mode_870155_aa; 38 39 /* Configure SMFI for LGMR */ 40 pnp_enter_conf_mode(&dev); 41 pnp_set_logical_device(&dev); 42 pnp_set_enable(&dev, 1); ** CID 1501088: Code maintainability issues (UNUSED_VALUE) /src/cpu/intel/slot_1/l2_cache.c: 152 in calculate_l2_latency() ________________________________________________________________________________________________________ *** CID 1501088: Code maintainability issues (UNUSED_VALUE) /src/cpu/intel/slot_1/l2_cache.c: 152 in calculate_l2_latency() 146 printk(BIOS_DEBUG, "L2 latency type = %x\n", t); 147 148 /* Get CPUID family/model */ 149 signature = cpuid_eax(1) & 0xfff0; 150 151 /* Read EBL_CR_POWERON */ >>> CID 1501088: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "rdmsr(42U)" to "msr" here, but that stored value is overwritten before it can be used. 152 msr = rdmsr(EBL_CR_POWERON); 153 /* Get clock multiplier and FSB frequency. 154 * Multiplier is in [25:22]. 155 * FSB is in [19:18] in Katmai, [19] in Deschutes ([18] is zero 156 * for them). 157 */ ** CID 1501087: (STRING_OVERFLOW) ________________________________________________________________________________________________________ *** CID 1501087: (STRING_OVERFLOW) /src/arch/x86/smbios.c: 1138 in smbios_write_type39() 1132 1133 t->power_unit_group = unit_group; 1134 t->location = smbios_add_string(t->eos, loc); 1135 t->device_name = smbios_add_string(t->eos, dev_name); 1136 t->manufacturer = smbios_add_string(t->eos, man); 1137 t->serial_number = smbios_add_string(t->eos, serial_num); >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "tag_num" without checking the length. 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); 1139 t->model_part_number = smbios_add_string(t->eos, part_num); 1140 t->revision_level = smbios_add_string(t->eos, rev_lvl); 1141 t->max_power_capacity = max_pow_cap; 1142 1143 ps_type = ps_ch->power_supply_type & 0xF; /src/arch/x86/smbios.c: 1140 in smbios_write_type39() 1134 t->location = smbios_add_string(t->eos, loc); 1135 t->device_name = smbios_add_string(t->eos, dev_name); 1136 t->manufacturer = smbios_add_string(t->eos, man); 1137 t->serial_number = smbios_add_string(t->eos, serial_num); 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); 1139 t->model_part_number = smbios_add_string(t->eos, part_num); >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "rev_lvl" without checking the length. 1140 t->revision_level = smbios_add_string(t->eos, rev_lvl); 1141 t->max_power_capacity = max_pow_cap; 1142 1143 ps_type = ps_ch->power_supply_type & 0xF; 1144 ps_status = ps_ch->power_supply_status & 0x7; 1145 vol_switch = ps_ch->input_voltage_range_switch & 0xF; /src/arch/x86/smbios.c: 1134 in smbios_write_type39() 1128 sizeof(*t), *handle); 1129 1130 uint16_t val = 0; 1131 uint16_t ps_type, ps_status, vol_switch, ps_unplug, ps_present, hot_rep; 1132 1133 t->power_unit_group = unit_group; >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "loc" without checking the length. 1134 t->location = smbios_add_string(t->eos, loc); 1135 t->device_name = smbios_add_string(t->eos, dev_name); 1136 t->manufacturer = smbios_add_string(t->eos, man); 1137 t->serial_number = smbios_add_string(t->eos, serial_num); 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); 1139 t->model_part_number = smbios_add_string(t->eos, part_num); /src/arch/x86/smbios.c: 1139 in smbios_write_type39() 1133 t->power_unit_group = unit_group; 1134 t->location = smbios_add_string(t->eos, loc); 1135 t->device_name = smbios_add_string(t->eos, dev_name); 1136 t->manufacturer = smbios_add_string(t->eos, man); 1137 t->serial_number = smbios_add_string(t->eos, serial_num); 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "part_num" without checking the length. 1139 t->model_part_number = smbios_add_string(t->eos, part_num); 1140 t->revision_level = smbios_add_string(t->eos, rev_lvl); 1141 t->max_power_capacity = max_pow_cap; 1142 1143 ps_type = ps_ch->power_supply_type & 0xF; 1144 ps_status = ps_ch->power_supply_status & 0x7; /src/arch/x86/smbios.c: 1135 in smbios_write_type39() 1129 1130 uint16_t val = 0; 1131 uint16_t ps_type, ps_status, vol_switch, ps_unplug, ps_present, hot_rep; 1132 1133 t->power_unit_group = unit_group; 1134 t->location = smbios_add_string(t->eos, loc); >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "dev_name" without checking the length. 1135 t->device_name = smbios_add_string(t->eos, dev_name); 1136 t->manufacturer = smbios_add_string(t->eos, man); 1137 t->serial_number = smbios_add_string(t->eos, serial_num); 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); 1139 t->model_part_number = smbios_add_string(t->eos, part_num); 1140 t->revision_level = smbios_add_string(t->eos, rev_lvl); /src/arch/x86/smbios.c: 1136 in smbios_write_type39() 1130 uint16_t val = 0; 1131 uint16_t ps_type, ps_status, vol_switch, ps_unplug, ps_present, hot_rep; 1132 1133 t->power_unit_group = unit_group; 1134 t->location = smbios_add_string(t->eos, loc); 1135 t->device_name = smbios_add_string(t->eos, dev_name); >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "man" without checking the length. 1136 t->manufacturer = smbios_add_string(t->eos, man); 1137 t->serial_number = smbios_add_string(t->eos, serial_num); 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); 1139 t->model_part_number = smbios_add_string(t->eos, part_num); 1140 t->revision_level = smbios_add_string(t->eos, rev_lvl); 1141 t->max_power_capacity = max_pow_cap; /src/arch/x86/smbios.c: 1137 in smbios_write_type39() 1131 uint16_t ps_type, ps_status, vol_switch, ps_unplug, ps_present, hot_rep; 1132 1133 t->power_unit_group = unit_group; 1134 t->location = smbios_add_string(t->eos, loc); 1135 t->device_name = smbios_add_string(t->eos, dev_name); 1136 t->manufacturer = smbios_add_string(t->eos, man); >>> CID 1501087: (STRING_OVERFLOW) >>> You might overrun the 2-character fixed-size string "t->eos" by copying "serial_num" without checking the length. 1137 t->serial_number = smbios_add_string(t->eos, serial_num); 1138 t->asset_tag_number = smbios_add_string(t->eos, tag_num); 1139 t->model_part_number = smbios_add_string(t->eos, part_num); 1140 t->revision_level = smbios_add_string(t->eos, rev_lvl); 1141 t->max_power_capacity = max_pow_cap; 1142 ** CID 1501086: API usage errors (BAD_COMPARE) /src/device/oprom/yabel/biosemu.c: 200 in biosemu() ________________________________________________________________________________________________________ *** CID 1501086: API usage errors (BAD_COMPARE) /src/device/oprom/yabel/biosemu.c: 200 in biosemu() 194 clr_ci(); 195 my_wrb((uintptr_t)mem_img + i, c); 196 } 197 #endif 198 copy_count++; 199 set_ci(); >>> CID 1501086: API usage errors (BAD_COMPARE) >>> Truncating the result of "memcmp" to "unsigned char" may cause it to be misinterpreted as 0. Note that "memcmp" may return an integer besides -1, 0, or 1. 200 cmp_result = memcmp(mem_img, rom_image, bios_device.img_size); 201 clr_ci(); 202 } 203 while ((copy_count < 5) && (cmp_result != 0)); 204 if (cmp_result != 0) { 205 printf ** CID 1501085: Control flow issues (DEADCODE) /src/device/oprom/yabel/interrupt.c: 299 in handleInt16() ________________________________________________________________________________________________________ *** CID 1501085: Control flow issues (DEADCODE) /src/device/oprom/yabel/interrupt.c: 299 in handleInt16() 293 /* TODO: we need getchar... */ 294 c = -1; //getchar(); 295 if (c == -1) { 296 // no key available 297 SET_FLAG(F_ZF); 298 } else { >>> CID 1501085: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "*keycode = c;". 299 *keycode = c; 300 301 // since after an ESC it may take a while to receive the next char, 302 // we send something that is not shown on the screen, and then try to get 303 // the next char 304 // TODO: only after ESC?? what about other multibyte keys ** CID 1501084: (UNUSED_VALUE) /src/device/oprom/x86emu/decode.c: 829 in decode_sib_address() /src/device/oprom/x86emu/decode.c: 834 in decode_sib_address() ________________________________________________________________________________________________________ *** CID 1501084: (UNUSED_VALUE) /src/device/oprom/x86emu/decode.c: 829 in decode_sib_address() 823 DECODE_PRINTF2("[%d]", displacement); 824 offset = displacement; 825 break; 826 case 1: 827 displacement = (s8)fetch_byte_imm(); 828 DECODE_PRINTF2("[%d][EBP]", displacement); >>> CID 1501084: (UNUSED_VALUE) >>> Assigning value from "_X86EMU_env.x86.spc.BP.I32_reg.e_reg + displacement" to "offset" here, but that stored value is overwritten before it can be used. 829 offset = M.x86.R_EBP + displacement; 830 break; 831 case 2: 832 displacement = (s32)fetch_long_imm(); 833 DECODE_PRINTF2("[%d][EBP]", displacement); 834 offset = M.x86.R_EBP + displacement; /src/device/oprom/x86emu/decode.c: 834 in decode_sib_address() 828 DECODE_PRINTF2("[%d][EBP]", displacement); 829 offset = M.x86.R_EBP + displacement; 830 break; 831 case 2: 832 displacement = (s32)fetch_long_imm(); 833 DECODE_PRINTF2("[%d][EBP]", displacement); >>> CID 1501084: (UNUSED_VALUE) >>> Assigning value from "_X86EMU_env.x86.spc.BP.I32_reg.e_reg + displacement" to "offset" here, but that stored value is overwritten before it can be used. 834 offset = M.x86.R_EBP + displacement; 835 break; 836 default: 837 HALT_SYS(); 838 } 839 DECODE_PRINTF("[EAX]"); ** CID 1501083: Null pointer dereferences (FORWARD_NULL) /src/device/oprom/yabel/biosemu.c: 246 in biosemu() ________________________________________________________________________________________________________ *** CID 1501083: Null pointer dereferences (FORWARD_NULL) /src/device/oprom/yabel/biosemu.c: 246 in biosemu() 240 my_wrl(0x1a * 4, 0xf000fe6e); 241 my_wrb(0x000ffe6e, 0xcf); 242 243 // setup BIOS Data Area (0000:04xx, or 0040:00xx) 244 // we currently 0 this area, meaning "we don't have 245 // any hardware" :-) no serial/parallel ports, floppys, ... >>> CID 1501083: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "biosmem + 1024" to "memset", which dereferences it. [Note: The source code implementation of the function has been overridden by a builtin model.] 246 memset(biosmem + 0x400, 0x0, 0x100); 247 248 // at offset 13h in BDA is the memory size in kbytes 249 my_wrw(0x413, biosmem_size / 1024); 250 // at offset 0eh in BDA is the segment of the Extended BIOS Data Area 251 // see setup further down ** CID 1299819: (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 2136 in idiv_long() /src/device/oprom/x86emu/prim_ops.c: 2136 in idiv_long() /src/device/oprom/x86emu/prim_ops.c: 2143 in idiv_long() /src/device/oprom/x86emu/prim_ops.c: 2136 in idiv_long() ________________________________________________________________________________________________________ *** CID 1299819: (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 2136 in idiv_long() 2130 do { 2131 div <<= 1; 2132 carry = (l_dvd >= l_s) ? 0 : 1; 2133 2134 if (abs_h_dvd < (h_s + carry)) { 2135 h_s >>= 1; >>> CID 1299819: (BAD_SHIFT) >>> In expression "abs_s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2136 l_s = abs_s << (--counter); 2137 continue; 2138 } else { 2139 abs_h_dvd -= (h_s + carry); 2140 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2141 : (l_dvd - l_s); /src/device/oprom/x86emu/prim_ops.c: 2136 in idiv_long() 2130 do { 2131 div <<= 1; 2132 carry = (l_dvd >= l_s) ? 0 : 1; 2133 2134 if (abs_h_dvd < (h_s + carry)) { 2135 h_s >>= 1; >>> CID 1299819: (BAD_SHIFT) >>> In expression "abs_s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2136 l_s = abs_s << (--counter); 2137 continue; 2138 } else { 2139 abs_h_dvd -= (h_s + carry); 2140 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2141 : (l_dvd - l_s); /src/device/oprom/x86emu/prim_ops.c: 2143 in idiv_long() 2137 continue; 2138 } else { 2139 abs_h_dvd -= (h_s + carry); 2140 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2141 : (l_dvd - l_s); 2142 h_s >>= 1; >>> CID 1299819: (BAD_SHIFT) >>> In expression "abs_s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2143 l_s = abs_s << (--counter); 2144 div |= 1; 2145 continue; 2146 } 2147 2148 } while (counter > -1); /src/device/oprom/x86emu/prim_ops.c: 2136 in idiv_long() 2130 do { 2131 div <<= 1; 2132 carry = (l_dvd >= l_s) ? 0 : 1; 2133 2134 if (abs_h_dvd < (h_s + carry)) { 2135 h_s >>= 1; >>> CID 1299819: (BAD_SHIFT) >>> In expression "abs_s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2136 l_s = abs_s << (--counter); 2137 continue; 2138 } else { 2139 abs_h_dvd -= (h_s + carry); 2140 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2141 : (l_dvd - l_s); ** CID 1299818: (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 2260 in div_long() /src/device/oprom/x86emu/prim_ops.c: 2260 in div_long() /src/device/oprom/x86emu/prim_ops.c: 2260 in div_long() /src/device/oprom/x86emu/prim_ops.c: 2267 in div_long() ________________________________________________________________________________________________________ *** CID 1299818: (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 2260 in div_long() 2254 do { 2255 div <<= 1; 2256 carry = (l_dvd >= l_s) ? 0 : 1; 2257 2258 if (h_dvd < (h_s + carry)) { 2259 h_s >>= 1; >>> CID 1299818: (BAD_SHIFT) >>> In expression "s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2260 l_s = s << (--counter); 2261 continue; 2262 } else { 2263 h_dvd -= (h_s + carry); 2264 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2265 : (l_dvd - l_s); /src/device/oprom/x86emu/prim_ops.c: 2260 in div_long() 2254 do { 2255 div <<= 1; 2256 carry = (l_dvd >= l_s) ? 0 : 1; 2257 2258 if (h_dvd < (h_s + carry)) { 2259 h_s >>= 1; >>> CID 1299818: (BAD_SHIFT) >>> In expression "s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2260 l_s = s << (--counter); 2261 continue; 2262 } else { 2263 h_dvd -= (h_s + carry); 2264 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2265 : (l_dvd - l_s); /src/device/oprom/x86emu/prim_ops.c: 2260 in div_long() 2254 do { 2255 div <<= 1; 2256 carry = (l_dvd >= l_s) ? 0 : 1; 2257 2258 if (h_dvd < (h_s + carry)) { 2259 h_s >>= 1; >>> CID 1299818: (BAD_SHIFT) >>> In expression "s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2260 l_s = s << (--counter); 2261 continue; 2262 } else { 2263 h_dvd -= (h_s + carry); 2264 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2265 : (l_dvd - l_s); /src/device/oprom/x86emu/prim_ops.c: 2267 in div_long() 2261 continue; 2262 } else { 2263 h_dvd -= (h_s + carry); 2264 l_dvd = carry ? ((0xFFFFFFFF - l_s) + l_dvd + 1) 2265 : (l_dvd - l_s); 2266 h_s >>= 1; >>> CID 1299818: (BAD_SHIFT) >>> In expression "s << --counter", shifting by a negative amount has undefined behavior. The shift amount, "--counter", is as little as -1. 2267 l_s = s << (--counter); 2268 div |= 1; 2269 continue; 2270 } 2271 2272 } while (counter > -1); ** CID 1198906: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 835 in rcl_long() ________________________________________________________________________________________________________ *** CID 1198906: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 835 in rcl_long() 829 { 830 u32 res, cnt, mask, cf; 831 832 res = d; 833 if ((cnt = s % 33) != 0) { 834 cf = (d >> (32 - cnt)) & 0x1; >>> CID 1198906: Integer handling issues (BAD_SHIFT) >>> In expression "d << cnt", left shifting by more than 31 bits has undefined behavior. The shift amount, "cnt", is as much as 32. 835 res = (d << cnt) & 0xffffffff; 836 mask = (1 << (cnt - 1)) - 1; 837 res |= (d >> (33 - cnt)) & mask; 838 if (ACCESS_FLAG(F_CF)) { /* carry flag is set */ 839 res |= 1 << (cnt - 1); 840 } ** CID 1198905: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 904 in rcr_byte() ________________________________________________________________________________________________________ *** CID 1198905: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 904 in rcr_byte() 898 This is effectively done by shifting the 899 object to the right. The result must be masked, 900 in case the object came in and was treated 901 as a negative number. Needed??? */ 902 903 mask = (1 << (8 - cnt)) - 1; >>> CID 1198905: Integer handling issues (BAD_SHIFT) >>> In expression "d >> cnt", right shifting "d" by more than 7 bits always yields zero. The shift amount, "cnt", is as much as 8. 904 res = (d >> cnt) & mask; 905 906 /* now the high stuff which rotated around 907 into the positions B_cnt-2 .. B_0 */ 908 /* B_(7) .. B_(8-(n-1)) <- b_(n-2) .. b_(0) */ 909 /* shift it downward, 7-(n-2) = 9-n positions. ** CID 1198904: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 982 in rcr_long() ________________________________________________________________________________________________________ *** CID 1198904: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 982 in rcr_long() 976 if (cnt == 1) { 977 cf = d & 0x1; 978 ocf = ACCESS_FLAG(F_CF) != 0; 979 } else 980 cf = (d >> (cnt - 1)) & 0x1; 981 mask = (1 << (32 - cnt)) - 1; >>> CID 1198904: Integer handling issues (BAD_SHIFT) >>> In expression "d >> cnt", right shifting by more than 31 bits has undefined behavior. The shift amount, "cnt", is as much as 32. 982 res = (d >> cnt) & mask; 983 if (cnt != 1) 984 res |= (d << (33 - cnt)); 985 if (ACCESS_FLAG(F_CF)) { /* carry flag is set */ 986 res |= 1 << (32 - cnt); 987 } ** CID 1198903: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 950 in rcr_word() ________________________________________________________________________________________________________ *** CID 1198903: Integer handling issues (BAD_SHIFT) /src/device/oprom/x86emu/prim_ops.c: 950 in rcr_word() 944 if (cnt == 1) { 945 cf = d & 0x1; 946 ocf = ACCESS_FLAG(F_CF) != 0; 947 } else 948 cf = (d >> (cnt - 1)) & 0x1; 949 mask = (1 << (16 - cnt)) - 1; >>> CID 1198903: Integer handling issues (BAD_SHIFT) >>> In expression "d >> cnt", right shifting "d" by more than 15 bits always yields zero. The shift amount, "cnt", is as much as 16. 950 res = (d >> cnt) & mask; 951 res |= (d << (17 - cnt)); 952 if (ACCESS_FLAG(F_CF)) { 953 res |= 1 << (16 - cnt); 954 } 955 CONDITIONAL_SET_FLAG(cf, F_CF); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

New list member..and a project
by Wayne Stuart 21 Nov '22

21 Nov '22

Hi, I just joined this list. I have a project coming up where I need to coreboot a Lenovo W540. I have found a mention of using the t440p setup. I am new to coreboot, though I have used coreboot laptops for a few years. I am looking for direction. Wayne

3 2

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