coreboot

coreboot@coreboot.org

6 participants
39686 discussions

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

21 Jun '23

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

2 1

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

16 Jun '23

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

1 0

How to build UEFI payload for Coreboot?
by Sarawadi, Ravishankar 15 Jun '23

15 Jun '23

Is EDK2/Tianocore payload not supported for coreboot on latest tip? Any build and interation steps for how-to for UEFI payload on top of coreboot? Thanks, -Ravi

2 3

Builds of Google boards fail due to FSP size
by Felix Singer 08 Jun '23

08 Jun '23

Hello, Moving forward the submodule pointers of the microcode [1] or Intel FSP [2][3] repository will make the Google boards (ChromeOS builds?) failing because the FSP does not fit into their flash region anymore. How do we deal with that issue? I think there are two options: * Make the flash regions bigger * Disable ChromeOS builds for upstream Best Felix --- [1] https://review.coreboot.org/c/coreboot/+/75631 [2] https://review.coreboot.org/c/coreboot/+/74242 [3] https://review.coreboot.org/c/coreboot/+/74442

4 5

Erying Tigerlake HM570 Micro-ATX motherboard S3 memory power gate..
by Timothy Potter 08 Jun '23

08 Jun '23

I've been looking at the work being done here https://github.com/ellyq/coreboot to get coreboot as an alternative to Erying's flaky BIOS. I'm particularly interested in getting S3 suspend working. From what I can see, the motherboard suspends correctly, but doesn't maintain power to the DRAM, so resets when it resumes. Given Erying won't provided schematics for the motherboard, is there any other way to work out how to "gate" the DRAM power reset signal? I assume it's controlled by a GPIO pin on the PCH/CPU. Are there standard pin assignments for these signals? I see some references to it in the codebase with respect to Lenovo using a different pin. Thanks, Tim.

2 1

Re: Builds of Google boards fail due to FSP size
by Subrata Banik 08 Jun '23

08 Jun '23

HI Paul and Team, I guess there is some kind of miscommunication between the usage of FSP blobs by the Google team for ChromeOS devices that Intel share via their GitHub repo. I didn't check. As Subrata explained in his comments[1], Google seems > to use some sort of customized FSP binary, which is built from an > internal repository and also stripped. So I was thinking that might be > the reason for that issue, because related ChromeOS flashmaps are > optimized for their FSP binary and not for the one from the public > Intel repo. Let me clarify, the changes that I have mentioned in my blog post earlier is done in context of Alder Lake (Brya variant devices) to optimize the FSP blobs (a post processing of the FSP blobs) but it doesn't mean that we have optimized the ChromeOS FMD (SPI layout) to take advantage of the optimized FSP blobs. Please take a look into the "chromeos.fmd" file history. https://github.com/coreboot/coreboot/commits/master/src/mainboard/google/br… We need to check why the updated FSP blob is breaking the ChromeOS devices but as mentioned above the FSP binary that we are using from Intel release source GitHub and we haven't limited the SPI layout to encash those savings yet. Let me know if you are looking for some clarification. Thanks, Subrata > > > From: Felix Singer <felixsinger(a)posteo.net> > Date: Wed, Jun 7, 2023 at 4:56 PM > Subject: [coreboot] Re: Builds of Google boards fail due to FSP size > To: Paul Menzel <pmenzel(a)molgen.mpg.de>, <coreboot(a)coreboot.org> > > > Hi Paul, > > On Wed, 2023-06-07 at 08:09 +0200, Paul Menzel wrote: > > Excuse my ignorance. How can all Google boards fail? Aren’t there > > Intel hardware generations where FSP should not be updated anymore? > > I was unclear, sorry. Only the Alderlake boards are affected as it > seems. > > > > Also, how much space is missing? Why did FSP grow that much? > > I didn't check. As Subrata explained in his comments[1], Google seems > to use some sort of customized FSP binary, which is built from an > internal repository and also stripped. So I was thinking that might be > the reason for that issue, because related ChromeOS flashmaps are > optimized for their FSP binary and not for the one from the public > Intel repo. > > > > Could a third option be to ask the FSP folks to provide smaller > > blobs? > > I don't know how feasible that is. From recent discussions about > releasing FSP binaries, it's even a thing to get *any* FSP binary > uploaded on the FSP repo. > > However, I think the best compromise is the one I wrote in my second > mail, which is to use only the FSP headers from the repo but not the > binaries for ChromeOS builds. Customized binaries can still be added by > the build system or manually. > > For the coreboot CI it shouldn't make much difference (probably not > anything?) because it does only build-tests and there are still enough > other boards to build-test that part. > > > Best > > Felix > > --- > [1] https://review.coreboot.org/c/coreboot/+/74442 > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

Question on coreboot with grub4dos legacy and UEFI?
by Michael D. Setzer II 06 Jun '23

06 Jun '23

Have a project G4L that does disk imaging. Just released a new version and have a user that downloaded it, but fails to boot on his laptop with coreboot?? The image file contains both the grub4dos legacy boot loader, and the grub4dos efi boot loader. Works fine on my systems, and with virtual box as well. Does not support secure boot, since kernels are not blessed with Microsoft certificates. Not sure if there is something that would need to be done to get it to work with grub4dos? Project is on sourceforge?? +------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+

1 0

New on blogs.coreboot.org: coreboot versions 4.20 and 4.20.1 have been released
by blogs.coreboot.org 04 Jun '23

04 Jun '23

1 0

Planned maintenance on ticket.coreboot.org on July 1st
by Felix Singer 01 Jun '23

01 Jun '23

I will do some maintenance work on our ticket system on July 1st, which is the upcoming Thursday. The maintenance will * start at 9:00 am UTC+0 * end at 11:00 am UTC+0 (estimated, probably at latest) During this time, the ticket system will be down and/or unusable. I will announce as soon as the work is finished. The maintenance will cover: * Updating the system to the newest stable release * Updating the ticket system to the newest stable release Felix

1 4

[coreboot - Other #492] (New) Evaluate changes need to be made to support Intel's X86S ISA changes
by Martin Roth 28 May '23

28 May '23

Issue #492 has been reported by Martin Roth. ---------------------------------------- Other #492: Evaluate changes need to be made to support Intel's X86S ISA changes https://ticket.coreboot.org/issues/492 * Author: Martin Roth * Status: New * Priority: Normal * Category: coreboot common code * Target version: none * Start date: 2023-05-28 ---------------------------------------- This past week, Intel announced a plan to boot directly to 64-bit mode[1]. While the timeline released with the announcement does't have any dates for the implementation, due to the huge impact this will have on coreboot, it seems appropriate to start looking at what changes will need to be made to support these changes to the ISA. Changes currently listed: Changes in X86-S ISA consist of: - restricting the CPU to be always in paged mode - removing 32-bit ring 0, as well as vm86 mode. - removing ring 1 and ring 2 - removing 16-bit real and protected modes - removing 16-bit addressing - removing fixed MTRRs - removing user-level I/O and string I/O - removing CR0 Write-Through mode - removing legacy FPU control bits in CR0 - removing ring 3 interrupt flag control - removing obsolete CR access instruction - rearchitecting INIT/SIPI - adding a new mechanism to switch between 4- and 5-level page tables - removing XAPIC and only supporting x2APIC - removing APIC support for 8529 - removing the disabling of NX or SYSCALL or long mode in the EFER MSR - removing the #SS and #NP exceptions - supporting a subset of segmentation architecture, with the following conditions: o restricted to a subset of IDT event delivery o base only for FS, GS o base and limit for GDT, IDT, and TSS o no limit on data or code fetches in 32-bit mode (similar to 64-bit) o no AR or unusable selector checking on CS, DS, ES, FS, and GS on data or code fetches in any mode o restricted support for far call, far return, far jump, and IRET (like FRED). 1: https://web.archive.org/web/20230526070811/https://www.intel.com/content/ww… -- 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 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot