coreboot July 2019

coreboot@coreboot.org

39 participants
48 discussions

Start a nNew thread

New on blogs.coreboot.org:
by blogs.coreboot.org 24 Jul '19

24 Jul '19

1 0

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

23 Jul '19

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 49 new defect(s) introduced to coreboot found with Coverity Scan. 124 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 49 defect(s) ** CID 1403651: Control flow issues (DEADCODE) /src/mainboard/purism/librem_skl/hda_verb.c: 51 in mb_hda_codec_init() ________________________________________________________________________________________________________ *** CID 1403651: Control flow issues (DEADCODE) /src/mainboard/purism/librem_skl/hda_verb.c: 51 in mb_hda_codec_init() 45 struct resource *res; 46 u32 codec_mask; 47 struct device *dev; 48 49 dev = SA_DEV_ROOT; 50 /* Check if HDA is enabled, else return */ >>> CID 1403651: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "dev->chip_info == NULL" inside this statement: "if (dev == NULL || dev->chi...". 51 if (dev == NULL || dev->chip_info == NULL) 52 return; 53 54 config = dev->chip_info; 55 56 /* ** CID 1403002: (UNINIT) /src/soc/mediatek/mt8183/dramc_pi_calibration_api.c: 548 in dramc_find_gating_window() /src/soc/mediatek/mt8183/dramc_pi_calibration_api.c: 542 in dramc_find_gating_window() ________________________________________________________________________________________________________ *** CID 1403002: (UNINIT) /src/soc/mediatek/mt8183/dramc_pi_calibration_api.c: 548 in dramc_find_gating_window() 542 pass_count_1[dqs]++; 543 544 if (pass_begin[dqs] == 1 && 545 pass_count_1[dqs] * DQS_GW_FINE_STEP > DQS_GW_FINE_END) 546 dqs_high[dqs] = 0; 547 >>> CID 1403002: (UNINIT) >>> Using uninitialized value "pass_count_1[0]". 548 if (pass_count_1[0] * DQS_GW_FINE_STEP > DQS_GW_FINE_END && 549 pass_count_1[1] * DQS_GW_FINE_STEP > DQS_GW_FINE_END) { 550 dramc_dbg("All bytes gating window > 1 coarse_tune," 551 " Early break\n"); 552 *dly_fine_xt = DQS_GW_FINE_END; 553 *coarse_tune = GATING_END; /src/soc/mediatek/mt8183/dramc_pi_calibration_api.c: 542 in dramc_find_gating_window() 536 dramc_dbg("[Byte %d]First pass (%d, %d, %d)\n", 537 dqs, dly_coarse_large, 538 dly_coarse_0p5t, *dly_fine_xt); 539 } 540 541 if (pass_begin[dqs] == 1) >>> CID 1403002: (UNINIT) >>> Using uninitialized value "pass_count_1[dqs]". 542 pass_count_1[dqs]++; 543 544 if (pass_begin[dqs] == 1 && 545 pass_count_1[dqs] * DQS_GW_FINE_STEP > DQS_GW_FINE_END) 546 dqs_high[dqs] = 0; 547 ** CID 1403001: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1403001: Null pointer dereferences (FORWARD_NULL) /src/soc/mediatek/mt8183/gpio.c: 184 in gpio_set_spi_driving() 178 case 5: 179 reg = (void *)(IOCFG_LM_BASE + GPIO_DRV0_OFFSET); 180 offset = 8; 181 break; 182 } 183 >>> CID 1403001: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "reg" to "read32", which dereferences it. 184 clrsetbits_le32(reg, 0xf << offset, reg_val << offset); ** CID 1401793: Insecure data handling (INTEGER_OVERFLOW) /3rdparty/vboot/futility/updater.c: 240 in host_get_platform_version() ________________________________________________________________________________________________________ *** CID 1401793: Insecure data handling (INTEGER_OVERFLOW) /3rdparty/vboot/futility/updater.c: 240 in host_get_platform_version() 234 /* Result should be 'revN' */ 235 if (strncmp(result, STR_REV, strlen(STR_REV)) == 0) 236 rev = strtol(result + strlen(STR_REV), NULL, 0); 237 DEBUG("Raw data = [%s], parsed version is %d", result, rev); 238 239 free(result); >>> CID 1401793: Insecure data handling (INTEGER_OVERFLOW) >>> Overflowed or truncated value (or a value computed from an overflowed or truncated value) "rev" used as return value. 240 return rev; 241 } 242 243 /* 244 * A helper function to invoke flashrom(8) command. 245 * Returns 0 if success, non-zero if error. ** CID 1401086: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1401086: Null pointer dereferences (FORWARD_NULL) /src/soc/qualcomm/qcs405/clock.c: 245 in clock_configure_spi() 239 } else if (blsp == 2) 240 spi_clk = (struct qcs405_clock *)&gcc->blsp2_qup0_spi_clk; 241 242 else 243 printk(BIOS_ERR, "BLSP%d not supported\n", blsp); 244 >>> CID 1401086: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "spi_clk" to "clock_configure", which dereferences it. 245 clock_configure(spi_clk, spi_cfg, hz, ARRAY_SIZE(spi_cfg)); 246 } 247 248 void clock_configure_i2c(uint32_t hz) 249 { 250 struct qcs405_clock *i2c_clk = ** CID 1398603: (CONSTANT_EXPRESSION_RESULT) /src/soc/mediatek/mt8183/dramc_pi_basic_api.c: 125 in transfer_pll_to_spm_control() /src/soc/mediatek/mt8183/dramc_pi_basic_api.c: 124 in transfer_pll_to_spm_control() ________________________________________________________________________________________________________ *** CID 1398603: (CONSTANT_EXPRESSION_RESULT) /src/soc/mediatek/mt8183/dramc_pi_basic_api.c: 125 in transfer_pll_to_spm_control() 119 (0xffff << 16) | (0x1 << 0), 120 (0xb16 << 16) | (0x1 << 0)); 121 122 /* Set SPM pinmux */ 123 clrbits_le32(&mtk_spm->pcm_pwr_io_en, (0xff << 0) | (0xff << 16)); 124 setbits_le32(&mtk_spm->dramc_dpy_clk_sw_con_sel, 0xffffffff); >>> CID 1398603: (CONSTANT_EXPRESSION_RESULT) >>> "((uint32_t)read32(&mtk_spm->dramc_dpy_clk_sw_con_sel2) & 4294967295U /* ~((uint32_t)0) */) | 0xffffffffU" is always 0xffffffff regardless of the values of its operands. This occurs as an argument to a function call. 125 setbits_le32(&mtk_spm->dramc_dpy_clk_sw_con_sel2, 0xffffffff); 126 127 setbits_le32(&mtk_spm->spm_power_on_val0, (0x1 << 8) | (0xf << 12)); 128 setbits_le32(&mtk_spm->spm_s1_mode_ch, 0x3 << 0); 129 130 shu_lev = (shu_lev == 1) ? 2 : 1; /src/soc/mediatek/mt8183/dramc_pi_basic_api.c: 124 in transfer_pll_to_spm_control() 118 clrsetbits_le32(&mtk_spm->poweron_config_set, 119 (0xffff << 16) | (0x1 << 0), 120 (0xb16 << 16) | (0x1 << 0)); 121 122 /* Set SPM pinmux */ 123 clrbits_le32(&mtk_spm->pcm_pwr_io_en, (0xff << 0) | (0xff << 16)); >>> CID 1398603: (CONSTANT_EXPRESSION_RESULT) >>> "((uint32_t)read32(&mtk_spm->dramc_dpy_clk_sw_con_sel) & 4294967295U /* ~((uint32_t)0) */) | 0xffffffffU" is always 0xffffffff regardless of the values of its operands. This occurs as an argument to a function call. 124 setbits_le32(&mtk_spm->dramc_dpy_clk_sw_con_sel, 0xffffffff); 125 setbits_le32(&mtk_spm->dramc_dpy_clk_sw_con_sel2, 0xffffffff); 126 127 setbits_le32(&mtk_spm->spm_power_on_val0, (0x1 << 8) | (0xf << 12)); 128 setbits_le32(&mtk_spm->spm_s1_mode_ch, 0x3 << 0); 129 ** CID 1394268: Possible Control flow issues (DEADCODE) /src/vendorcode/cavium/bdk/libdram/libdram.c: 187 in bdk_libdram_tune_node() ________________________________________________________________________________________________________ *** CID 1394268: Possible Control flow issues (DEADCODE) /src/vendorcode/cavium/bdk/libdram/libdram.c: 187 in bdk_libdram_tune_node() 181 } 182 183 // disabled by default for now, does not seem to be needed much? 184 // Automatically tune the ECC byte DLL read offsets 185 // FIXME? allow override of the filtering 186 // FIXME? allow programmatic override, not via envvar? >>> CID 1394268: Possible Control flow issues (DEADCODE) >>> Execution cannot reach the expression "lmc_config.s.mode32b == 0" inside this statement: "if (do_eccdll && !do_dllro_...". 187 if (do_eccdll && !do_dllro_hw && (lmc_config.s.mode32b == 0)) { // do not do HW-assist twice for ECC 188 BDK_TRACE(DRAM, "N%d: Starting ECC DLL Read Offset Tuning for LMCs\n", node); 189 errs = perform_HW_dll_offset_tuning(node, 2, 8/* ECC bytelane */); 190 BDK_TRACE(DRAM, "N%d: Finished ECC DLL Read Offset Tuning for LMCs, %d errors\n", 191 node, errs); 192 tot_errs += errs; ** CID 1393983: (INTEGER_OVERFLOW) /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1146 in initialize_ddr_clock() /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1150 in initialize_ddr_clock() ________________________________________________________________________________________________________ *** CID 1393983: (INTEGER_OVERFLOW) /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1146 in initialize_ddr_clock() 1140 best_en_idx = strtoul(s, NULL, 0); 1141 override_pll_settings = 1; 1142 } 1143 1144 if (override_pll_settings) { 1145 best_pll_MHz = ddr_ref_hertz * (best_clkf+1) / (best_clkr+1) / 1000000; >>> CID 1393983: (INTEGER_OVERFLOW) >>> Overflowed or truncated value (or a value computed from an overflowed or truncated value) "best_en_idx" used as array index. 1146 best_calculated_ddr_hertz = ddr_ref_hertz * (best_clkf + 1) / ((best_clkr + 1) * (_en[best_en_idx])); 1147 best_error = ddr_hertz - best_calculated_ddr_hertz; 1148 } 1149 1150 ddr_print("clkr: %2llu, en[%d]: %2d, clkf: %4llu, pll_MHz: %4llu, ddr_hertz: %8llu, error: %8lld <==\n", 1151 best_clkr, best_en_idx, _en[best_en_idx], best_clkf, best_pll_MHz, /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1150 in initialize_ddr_clock() 1144 if (override_pll_settings) { 1145 best_pll_MHz = ddr_ref_hertz * (best_clkf+1) / (best_clkr+1) / 1000000; 1146 best_calculated_ddr_hertz = ddr_ref_hertz * (best_clkf + 1) / ((best_clkr + 1) * (_en[best_en_idx])); 1147 best_error = ddr_hertz - best_calculated_ddr_hertz; 1148 } 1149 >>> CID 1393983: (INTEGER_OVERFLOW) >>> Overflowed or truncated value (or a value computed from an overflowed or truncated value) "best_en_idx" used as array index. 1150 ddr_print("clkr: %2llu, en[%d]: %2d, clkf: %4llu, pll_MHz: %4llu, ddr_hertz: %8llu, error: %8lld <==\n", 1151 best_clkr, best_en_idx, _en[best_en_idx], best_clkf, best_pll_MHz, 1152 best_calculated_ddr_hertz, best_error); 1153 1154 /* Try lowering the frequency if we can't get a working configuration */ 1155 if (best_error == ddr_hertz) { ** CID 1393982: Memory - illegal accesses (UNINIT) ________________________________________________________________________________________________________ *** CID 1393982: Memory - illegal accesses (UNINIT) /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 437 in report_ddr3_dimm() 431 volt_str = "1.5V"; 432 if (spd_voltage & 2) 433 volt_str = "1.35V"; 434 if (spd_voltage & 4) 435 volt_str = "1.2xV"; 436 >>> CID 1393982: Memory - illegal accesses (UNINIT) >>> Using uninitialized value "volt_str" when calling "report_common_dimm". 437 report_common_dimm(node, dimm_config, dimm, ddr3_dimm_types, 438 DDR3_DRAM, volt_str, ddr_interface_num, 439 num_ranks, dram_width, dimm_size_mb); 440 } 441 442 const char *ddr4_dimm_types[16] = { ** CID 1393981: Insecure data handling (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/dram-init-ddr3.c: 745 in Perform_Read_Deskew_Training() ________________________________________________________________________________________________________ *** CID 1393981: Insecure data handling (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/dram-init-ddr3.c: 745 in Perform_Read_Deskew_Training() 739 perform_octeon3_ddr3_sequence(node, rank_mask, ddr_interface_num, 0x0A); /* LMC Deskew Training */ 740 741 lock_retries = 0; 742 743 perform_read_deskew_training: 744 // maybe perform the NORMAL deskew training sequence multiple times before looking at lock status >>> CID 1393981: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "normal_loops" as a loop boundary. 745 for (loops = 0; loops < normal_loops; loops++) { 746 DRAM_CSR_MODIFY(phy_ctl, node, BDK_LMCX_PHY_CTL(ddr_interface_num), 747 phy_ctl.s.phy_dsk_reset = 0); /* Normal Deskew sequence */ 748 perform_octeon3_ddr3_sequence(node, rank_mask, ddr_interface_num, 0x0A); /* LMC Deskew Training */ 749 } 750 // Moved this from Validate_Read_Deskew_Training ** CID 1393980: Incorrect expression (NO_EFFECT) /src/vendorcode/cavium/bdk/libdram/libdram.c: 89 in bdk_dram_clear_mem() ________________________________________________________________________________________________________ *** CID 1393980: Incorrect expression (NO_EFFECT) /src/vendorcode/cavium/bdk/libdram/libdram.c: 89 in bdk_dram_clear_mem() 83 /* The above pointer got address 8 to avoid NULL pointer checking 84 in bdk_phys_to_ptr(). Correct it here */ 85 ptr--; 86 uint64_t *end = bdk_phys_to_ptr(bdk_numa_get_address(node, skip)); 87 while (ptr < end) 88 { >>> CID 1393980: Incorrect expression (NO_EFFECT) >>> Assigning "*ptr" to itself has no effect. 89 *ptr = *ptr; 90 ptr++; 91 } 92 } 93 ddr_print("N%d: Clearing DRAM: start 0x%llx length 0x%llx\n", node, skip, len); 94 bdk_zero_memory(bdk_phys_to_ptr(bdk_numa_get_address(node, skip)), len); ** CID 1393973: (DEADCODE) /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 101 in read_entire_spd() /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 112 in read_entire_spd() /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 120 in read_entire_spd() ________________________________________________________________________________________________________ *** CID 1393973: (DEADCODE) /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 101 in read_entire_spd() 95 uint32_t *ptr = (uint32_t *)spd_buf; 96 97 for (int bank = 0; bank < (spd_size >> 8); bank++) 98 { 99 /* this should only happen for DDR4, which has a second bank of 256 bytes */ 100 if (bank) >>> CID 1393973: (DEADCODE) >>> Execution cannot reach this statement: "bdk_twsix_write_ia(node, bu...". 101 bdk_twsix_write_ia(node, bus, 0x36 | bank, 0, 2, 1, 0); 102 int bank_size = 256; 103 for (int i = 0; i < bank_size; i += 4) 104 { 105 int64_t data = bdk_twsix_read_ia(node, bus, address, i, 4, 1); 106 if (data < 0) /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 112 in read_entire_spd() 106 if (data < 0) 107 { 108 free(spd_buf); 109 bdk_error("Failed to read SPD data at 0x%x\n", i + (bank << 8)); 110 /* Restore the bank to zero */ 111 if (bank) >>> CID 1393973: (DEADCODE) >>> Execution cannot reach this statement: "bdk_twsix_write_ia(node, bu...". 112 bdk_twsix_write_ia(node, bus, 0x36 | 0, 0, 2, 1, 0); 113 return -1; 114 } 115 else 116 *ptr++ = bdk_be32_to_cpu(data); 117 } /src/vendorcode/cavium/bdk/libdram/dram-spd.c: 120 in read_entire_spd() 114 } 115 else 116 *ptr++ = bdk_be32_to_cpu(data); 117 } 118 /* Restore the bank to zero */ 119 if (bank) >>> CID 1393973: (DEADCODE) >>> Execution cannot reach this statement: "bdk_twsix_write_ia(node, bu...". 120 bdk_twsix_write_ia(node, bus, 0x36 | 0, 0, 2, 1, 0); 121 } 122 123 /* Store the SPD in the device tree */ 124 /* FIXME(dhendrix): No need for this? cfg gets updated, so the caller 125 * (libdram_config()) has what it needs. */ ** CID 1393972: Insecure data handling (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/dram-tune-ddr3.c: 1011 in perform_dll_offset_tuning() ________________________________________________________________________________________________________ *** CID 1393972: Insecure data handling (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/dram-tune-ddr3.c: 1011 in perform_dll_offset_tuning() 1005 /* Disable l2 sets for DRAM testing */ 1006 limit_l2_ways(node, 0, ways_print); 1007 #endif 1008 1009 // testing is done on all LMCs simultaneously 1010 // FIXME: for now, loop here to show what happens multiple times >>> CID 1393972: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "loops" as a loop boundary. 1011 for (loop = 0; loop < loops; loop++) { 1012 /* Perform DLL offset tuning */ 1013 errs = auto_set_dll_offset(node, dll_offset_mode, num_lmcs, ddr_interface_64b, do_tune); 1014 } 1015 1016 #if USE_L2_WAYS_LIMIT ** CID 1393971: Insecure data handling (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1146 in initialize_ddr_clock() ________________________________________________________________________________________________________ *** CID 1393971: Insecure data handling (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1146 in initialize_ddr_clock() 1140 best_en_idx = strtoul(s, NULL, 0); 1141 override_pll_settings = 1; 1142 } 1143 1144 if (override_pll_settings) { 1145 best_pll_MHz = ddr_ref_hertz * (best_clkf+1) / (best_clkr+1) / 1000000; >>> CID 1393971: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "best_en_idx" as an index into an array "_en". 1146 best_calculated_ddr_hertz = ddr_ref_hertz * (best_clkf + 1) / ((best_clkr + 1) * (_en[best_en_idx])); 1147 best_error = ddr_hertz - best_calculated_ddr_hertz; 1148 } 1149 1150 ddr_print("clkr: %2llu, en[%d]: %2d, clkf: %4llu, pll_MHz: %4llu, ddr_hertz: %8llu, error: %8lld <==\n", 1151 best_clkr, best_en_idx, _en[best_en_idx], best_clkf, best_pll_MHz, ** CID 1393969: Possible Control flow issues (DEADCODE) /src/vendorcode/cavium/bdk/libbdk-hal/bdk-qlm.c: 421 in bdk_qlm_eye_display() ________________________________________________________________________________________________________ *** CID 1393969: Possible Control flow issues (DEADCODE) /src/vendorcode/cavium/bdk/libbdk-hal/bdk-qlm.c: 421 in bdk_qlm_eye_display() 415 result = 0; 416 } 417 else 418 result = -1; 419 420 if (need_free) >>> CID 1393969: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "free((void *)eye);". 421 free((void*)eye); 422 return result; ** CID 1393967: Code maintainability issues (UNUSED_VALUE) /src/vendorcode/cavium/bdk/libdram/dram-tune-ddr3.c: 658 in auto_set_dll_offset() ________________________________________________________________________________________________________ *** CID 1393967: Code maintainability issues (UNUSED_VALUE) /src/vendorcode/cavium/bdk/libdram/dram-tune-ddr3.c: 658 in auto_set_dll_offset() 652 } /* for (lmc = 0; lmc < num_lmcs; lmc++) */ 653 654 bdk_watchdog_poke(); 655 656 // run the test(s) 657 // only 1 call should be enough, let the bursts, etc, control the load... >>> CID 1393967: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "run_dram_tuning_threads(node, num_lmcs, bytemask)" to "tot_errors" here, but that stored value is overwritten before it can be used. 658 tot_errors = run_dram_tuning_threads(node, num_lmcs, bytemask); 659 660 for (lmc = 0; lmc < num_lmcs; lmc++) { 661 // record stop cycle CSRs here for utilization measure 662 stop_dram_dclk[lmc] = BDK_CSR_READ(node, BDK_LMCX_DCLK_CNT(lmc)); 663 stop_dram_ops[lmc] = BDK_CSR_READ(node, BDK_LMCX_OPS_CNT(lmc)); ** CID 1393966: Control flow issues (DEADCODE) /src/soc/cavium/cn81xx/uart.c: 104 in uart_platform_refclk() ________________________________________________________________________________________________________ *** CID 1393966: Control flow issues (DEADCODE) /src/soc/cavium/cn81xx/uart.c: 104 in uart_platform_refclk() 98 unsigned int uart_platform_refclk(void) 99 { 100 struct cn81xx_uart *uart = 101 (struct cn81xx_uart *)CONFIG_CONSOLE_SERIAL_UART_ADDRESS; 102 103 if (!uart) >>> CID 1393966: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "return 0U;". 104 return 0; 105 106 return uart_hclk(uart); 107 } 108 109 uintptr_t uart_platform_base(int idx) ** CID 1393965: Control flow issues (DEADCODE) /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1880 in dbi_switchover_interface() ________________________________________________________________________________________________________ *** CID 1393965: Control flow issues (DEADCODE) /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 1880 in dbi_switchover_interface() 1874 for (byte = 0; byte < (8+ecc_ena); byte++) { 1875 unlocked += (dbi_settings[byte] & 1) ^ 1; 1876 } 1877 1878 // FIXME: print out the DBI settings array after each rank? 1879 if (rank_max > 1) // only when doing more than 1 rank >>> CID 1393965: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "display_DAC_DBI_settings(no...". 1880 display_DAC_DBI_settings(node, lmc, /* DBI */0, ecc_ena, dbi_settings, " RANK"); 1881 1882 if (unlocked > 0) { 1883 ddr_print("N%d.LMC%d: DBI switchover: LOCK: %d still unlocked.\n", 1884 node, lmc, unlocked); 1885 ** CID 1393964: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1393964: (TAINTED_SCALAR) /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 682 in perform_ddr_init_sequence() 676 677 bdk_wait_usec(1000); /* Wait a while. */ 678 679 if ((s = lookup_env_parameter("ddr_sequence1")) != NULL) { 680 int sequence1; 681 sequence1 = strtoul(s, NULL, 0); >>> CID 1393964: (TAINTED_SCALAR) >>> Passing tainted variable "sequence1" to a tainted sink. 682 perform_octeon3_ddr3_sequence(node, (1 << rankx), 683 ddr_interface_num, sequence1); 684 } 685 686 if ((s = lookup_env_parameter("ddr_sequence2")) != NULL) { 687 int sequence2; /src/vendorcode/cavium/bdk/libdram/lib_octeon_shared.c: 689 in perform_ddr_init_sequence() 683 ddr_interface_num, sequence1); 684 } 685 686 if ((s = lookup_env_parameter("ddr_sequence2")) != NULL) { 687 int sequence2; 688 sequence2 = strtoul(s, NULL, 0); >>> CID 1393964: (TAINTED_SCALAR) >>> Passing tainted variable "sequence2" to a tainted sink. 689 perform_octeon3_ddr3_sequence(node, (1 << rankx), 690 ddr_interface_num, sequence2); 691 } 692 } 693 } 694 } ** CID 1393962: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1393962: Null pointer dereferences (FORWARD_NULL) /src/vendorcode/cavium/bdk/libbdk-dram/bdk-dram-test-addrbus.c: 64 in __bdk_dram_test_mem_address_bus() 58 { 59 int failures = 0; 60 61 /* Clear our work area. Checking for aliases later could get false 62 positives if it matched stale data */ 63 void *ptr = (area) ? bdk_phys_to_ptr(area) : NULL; >>> CID 1393962: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "ptr" to "bdk_zero_memory", which dereferences it. 64 bdk_zero_memory(ptr, max_address - area); 65 __bdk_dram_flush_to_mem_range(area, max_address); 66 67 /* Each time we write, we'll write this pattern xored the address it is 68 written too */ 69 uint64_t pattern = 0x0fedcba987654321; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Announcing coreboot 4.10
by Patrick Georgi 23 Jul '19

23 Jul '19

The 4.10 release covers commit a2faaa9a2 to commit ae317695e3 There is a pgp signed 4.10 tag in the git repository, and a branch will be created as needed. In nearly 8 months since 4.9 we had 198 authors commit 2538 changes to master. Of these, 85 authors made their first commit to coreboot: Welcome! Between the releases the tree grew by about 11000 lines of code plus 5000 lines of comments. Again, a big Thank You to all contributors who helped shape the coreboot project, community and code with their effort, no matter if through development, review, testing, documentation or by helping people asking questions on our venues like IRC or our mailing list. What's New ---------- Most of the changes were to mainboards, and on the chipset side, lots of activity concentrated on x86. However compared to previous releases activity (and therefore interest, probably) increased in vboot and in non-x86 architectures. However it's harder this time to give this release a single topic like the last: This release accumulates some of everything. Clean Up -------- As usual, there was a lot of cleaning up going on, and there notably, a good chunk of this year's Google Summer of Code project to clean out the issues reported by Coverity Scan is already in. The only larger scale change that was registered in the pre-release notes was also about cleaning up the tree: ### `device_t` is no more coreboot used to have a data type, `device_t` that changed shape depending on whether it is compiled for romstage (with limited memory) or ramstage (with unlimited memory as far as coreboot is concerned). It's an old relic from the time when romstage wasn't operated in Cache-As-RAM mode, but compiled with our romcc compiler. That data type is now gone. Release Notes maintenance ------------------------- Speaking of pre-release notes: After 4.10 we'll start a document for 4.11 in the git repository. Feel free to add notable achievements there so we remember to give them a shout out in the next release's notes. Known Issues ------------ Sadly, Google Cyan is broken in this release. It doesn't work with the "C environment" bootblock (as compared to the old romcc type bootblock) which is now the default. Sadly it doesn't help to simply revert that change because doing so breaks other boards. If you want to use Google Cyan with the release (or if you're tracking the master branch), please keep an eye on https://review.coreboot.org/c/coreboot/+/34304 where a solution for this issue is sought. Deprecations ------------ As announced in the 4.9 release notes, there are no deprecations after 4.10. While 4.10 is also released late and we target a 4.11 release in October we nonetheless want to announce deprecations this time: These are under discussion since January, people are working on mitigations for about as long and so it should be possible to resolve the outstanding issues by the end of October. Specifically, we want to require code to work with the following Kconfig options so we can remove the options and the code they disable: * C\_ENVIRONMENT\_BOOTBLOCK * NO\_CAR\_GLOBAL\_MIGRATION * RELOCATABLE\_RAMSTAGE These only affect x86. If your platform only works without them, please look into fixing that. Added 28 mainboards: -------------------- * ASROCK H110M-DVS * ASUS H61M-CS * ASUS P5G41T-M-LX * ASUS P5QPL-AM * ASUS P8Z77-M-PRO * FACEBOOK FBG1701 * FOXCONN G41M * GIGABYTE GA-H61MA-D3V * GOOGLE BLOOG * GOOGLE FLAPJACK * GOOGLE GARG * GOOGLE HATCH-WHL * GOOGLE HELIOS * GOOGLE KINDRED * GOOGLE KODAMA * GOOGLE KOHAKU * GOOGLE KRANE * GOOGLE MISTRAL * HP COMPAQ-8200-ELITE-SFF-PC * INTEL COMETLAKE-RVP * INTEL KBLRVP11 * LENOVO R500 * LENOVO X1 * MSI MS7707 * PORTWELL M107 * PURISM LIBREM13-V4 * PURISM LIBREM15-V4 * SUPERMICRO X10SLM-PLUS-F * UP SQUARED Removed 7 mainboards: --------------------- * GOOGLE BIP * GOOGLE DELAN * GOOGLE ROWAN * PCENGINES ALIX1C * PCENGINES ALIX2C * PCENGINES ALIX2D * PCENGINES ALIX6 Removed 3 processors: --------------------- * src/cpu/amd/geode\_lx * src/cpu/intel/model\_69x * src/cpu/intel/model\_6dx Added 2 socs: ------------- * src/soc/amd/picasso * src/soc/qualcomm/qcs405 Toolchain --------- * Update to gcc 8.3.0, binutils 2.32, IASL 20190509, clang 8 -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

Preparing for the 4.10 release
by Patrick Georgi 21 Jul '19

21 Jul '19

Hi everybody, I'm _really_ late with the 4.10 release and I'm sorry. Too much other things intervened and then there were a few issues on a couple of targets that were close to being fixed. While we don't provide any guarantees for our releases, they're still a good opportunity to try to wrap things up. I tested the commit in question on all QEmu targets and on Getac/P470, and it's looking reasonable. So in the light of getting things out, I prepared the release notes and pushed them to https://review.coreboot.org/c/coreboot/+/34469. Please take a look and comment if there's anything missing. I plan to put up the release on Monday evening European time (Monday morning in the US, early Tuesday in Asia). Thanks, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

X131e: Status, experiences and remaining problems
by Robin Haberkorn 20 Jul '19

20 Jul '19

Hello! I wanted to share my experiences with corebooting the X131e (Intel edition) and hope to be able to resolve some of the remaining issues. Previously I used a corebooted X131e Chromebook (Stout) and it worked perfectly - I didn't have any of the issues, which I'm going to detail further down. I got the X131e Intel as an "upgrade" and because I thought that migrating would be trivial. I'm using the same peripherals with the Intel boards, but installed new RAM. Turns out the stock BIOS had hardware whitelists, so that was a good pretext to try out coreboot. I based my build on the 4.9 release but ended up applying some X131e patches by James Ye, which are still pending in Gerrit. The following changes on top of 4.9 to be precise: commit b21539d2c4f57518b964949b30ebdd200a8d1f5a Author: James Ye <jye836(a)gmail.com> Date: Thu Jan 24 00:18:28 2019 +1100 mb/lenovo/x131e: add function key support Enables function keys for X131e. SMI handler based on google/stout. ACPI code and event masks are reverse-engineered. The IT8518e EC of this board uses some different ACPI methods compared to the regular Lenovo H8. Add an option to use the alternative set of methods. Change-Id: Ib3a01f37a8b54889b55e92c501c9350e6c68bd57 commit 178cf723697b9d069810fd404dcabd448d136503 Author: James Ye <jye836(a)gmail.com> Date: Fri Feb 1 13:29:02 2019 +1100 mb/lenovo/x131e: correct USB port config Based on schematic and register dumps. Change-Id: I91fc47022988cfe986fb8c1ed21dc073ee7d16bc commit 750432f7a1487175243065d95c57f9e0e6c21204 Author: James Ye <jye836(a)gmail.com> Date: Tue Feb 12 22:17:52 2019 +1100 mb/lenovo/x131e: enable mSATA slot Per google/stout. Functionality untested. Change-Id: I7cc9837f572236acac2007e95990e64c25a5d6e2 commit 151019a9d21c612834dacad649cde7aec3132844 Author: James Ye <jye836(a)gmail.com> Date: Sat Jan 19 18:25:44 2019 +1100 mb/lenovo/x131e: enable WWAN detection Per schematic. Non-presence is detected correctly, but presence is untested. Change-Id: I4cfefb06556c9d69bc8e4a4f9d112246885c253a commit 5bdb3cd2a802b0654feeeb19471c719db62a23c4 Author: James Ye <jye836(a)gmail.com> Date: Sat Jan 19 18:25:04 2019 +1100 mb/lenovo/x131e: remove PMH7 This board does not have PMH7. Change-Id: I382958f012e5f4445efc76c7f36bbdf460c29be4 commit 1cd0a5920fb93489aa1fe5b1c0be6170f88f23da Author: James Ye <jye836(a)gmail.com> Date: Thu Jan 17 22:00:14 2019 +1100 mb/lenovo/x131e: add VBT VBT was extracted from VBIOS ROM. Tested with libgfxinit, booting SeaBIOS into Linux. Change-Id: Ibedb43852dc9b846850e1070b84f708c847b7dbf Here's the board-status report: https://coreboot.org/status/board-status.html#lenovo/x131e The EC is probably rather old, as I didn't do a BIOS upgrade before flashing coreboot. If possible, I'd like to avoid upgrading the EC now, as that would require extracting it from the Lenove BIOS and programming it externally. Isn't it? Now regarding the remaining issues, in order of significance (for me): 1.) There are infrequent system freezes - possibly a kernel panic? - without any visible reason in the system journal. Unfortunately, I haven't run the board long enough on the original BIOS to judge whether this is Coreboot-specific. At least I tried performing some SMART and memtest86 tests - to no avail. 2.) At some point during my experimenting, only 4 of the 8GB RAM I've installed would be detected. This wasn't the case in the beginning, when I started out with a clean 4.9-build. I've attached a board status report from this time. Maybe somebody can see why the 2nd 4GB module is no longer detected. Naturally, one of the commits I later added might be responsible. If really necessary, I could do a git-dissect. 3.) The internal speakers __sometimes__ don't work after startup. They are simply mute. I initially thought this depends on the headphones being plugged in at boot, but there is no causal relation. None of the thinkpad_acpi-kernel-modules' `volume_*` params have any effect. Changing the settings of the enigmatic "ThinkPad Console Audio Control" sound card (created if volume_mode != 2 (N/A)) does not have any audible effect at all - even while headphones are working. Rerouting pins with hdajackretask does not help. Comparing Linux kernel logs (dmesg) does not yield any difference between working and non-working boots in the output of the relevant audio drivers. 4.) My 1600Mhz DDR3 RAM supposedly runs at 666Mhz (dmidecode --type 17). I think it's running at 1330 MHz, though. I somewhere read that 1600 Mhz CL11 is equivalent to 1300 Mhz CL9, which could explain this. So I guess, I simply bought crappy RAM. 5.) The Fn-keys work after the corresponding patch. But is it possible to use the Fn-key like any other (modifier) key? I do not get separate key-down/release events and events for any other key-presses (except for a few that have assigned Fn-functions). That's a bit of a waste. I guess, this is an EC "feature"... 6.) I have a WWAN mPCI card (Sierra 7710). It used to be reported as always-hard-blocked (rfkill list). WWAN was enabled in NVRAM. All of these (WIFI, Bluethooth, WWAN) Enable-NVRAM-settings have no effect on the hard-block state of any of the corresponding devices, though. thinkpad_acpi reads these values from the EC via ACPI as far as I could follow the sources. So I conclude that this is probably a Coreboot-EC-communication problem!? h8_wwan_enable() probably has no effect on this board. The infamous trick of taping the miniPCI pin 20 did not help either in unblocking the card. Neither did disabling power-off mode per AT commands on the modem. Turned out however that the card wasn't really physically blocked, as scanning would still work via modem-manager-gui. thinkpad_acpi simply reported it as blocked, which is probably what rfkill reported as well. So I was able to work around this issue with the following module params (e.g. store as /etc/modprobe.d/thinkpad_acpi.conf): options thinkpad_acpi dbg_wwanemul=1 wwan_state=1 dbg_wlswemul=1 wlsw_state=1 (Interestingly `dbg_wwanemul` seems to have no effect.) The modem now appears to work. 7.) The internal PS2 keyboard does not work in some secondary payloads (eg. nvramcui). Only USB-keyboards do. That's a bit annoying in a notebook, especially since... 8.) nvramtool crashes. Is that known and fixed, or would you like a core dump? Needless to mention that I enabled CONFIG_USE_OPTION_TABLE and nvramcui also generally works. 9.) Waking up from sleep-mode does not work. I haven't investigated this thoroughly and I haven't tested hibernation. Quite possibly an OS issue. 10.) Maybe off-topic, but relevant for anybody trying to coreboot this board: flashrom had to be patched in order to work with the flash chip. Turns out the probing/identification command would not be answered correctly by the chip (found out after attaching a logic analyzer), even though I checked against the datasheet. Didn't dive into this question too deeply but simply worked around it by letting flashrom skip the probing. Flashing externally is quite unreliable, and needs to be repeated often until a complete image would be flashed. This could be because of long and crappy wires, though. Internal flashing does currently not work. In a related matter: There is zero documentation on how to coreboot this board in the entire internet AFAIK. That's a bit sad, as it significantly decreases its possible audience and might also result in the port dying once the initial maintainer looses interest. Maybe including documentation should be made mandatory for every new port? I can also confirm that the WWAN detection (I4cfefb06556c9d69bc8e4a4f9d112246885c253a) works for detecting a card's presence as well. Any ideas, especially on how to proceed with 1.) and 2.)? Best regards, Robin

1 1

Re: Question how to write protect flash
by Public Email Account 20 Jul '19

20 Jul '19

Yes its sandy bridge. What is proper way to do this though. On flash descriptor (and if so, how?) or through coreboot option? Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, July 15, 2019 12:37 AM, werner.zeh(a)siemens.com <werner.zeh(a)siemens.com> wrote: > IIRC X220 uses Sandy Bridge. I think there is a flag somewhere in the descriptor where you can lock down your BIOS-region as read-only for the x86 host. > I never have tried it but in theory this should lead to errors on every write attempt to the BIOS region therefore disabling write access to the flash from OS/flashrom. > > Werner

4 5

New on blogs.coreboot.org: [GSoC] Ghidra firmware utilities, weeks 6-8
by blogs.coreboot.org 17 Jul '19

17 Jul '19

1 0

New on blogs.coreboot.org: [GSoC] How to Run C Code in Bootblock Stage for QEMU/AArch64
by blogs.coreboot.org 17 Jul '19

17 Jul '19

1 0

Request for review verified boot and measure boot implementation
by Frans Hendriks 17 Jul '19

17 Jul '19

Hi all, Have a few patchsets waiting for review related to vendor implementation of 'verified boot' and 'measure boot'. This implementation is working/booting on Facebook FBG1701 (Intel Braswell), but not chipset related. Anyone have time for review. Thanks in advance. Met vriendelijke groet / Best regards, Frans Hendriks www.eltan.com

1 0

Kernel Panics on corebooted systems with linux 4.19 ( >4.9)
by Kinky Nekoboi 16 Jul '19

16 Jul '19

Happend again for other Users/boards please somebody good investigate this further. see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930029 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931639

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2019