March 2018 - coreboot - mail.coreboot.org

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com March 23, 2018

March 23, 2018

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 21 new defect(s) introduced to coreboot found with Coverity Scan. 102 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 21 defect(s) ** CID 1387031: Memory - illegal accesses (BUFFER_SIZE_WARNING) /src/soc/amd/common/block/pi/amd_late_init.c: 52 in transfer_memory_info() ________________________________________________________________________________________________________ *** CID 1387031: Memory - illegal accesses (BUFFER_SIZE_WARNING) /src/soc/amd/common/block/pi/amd_late_init.c: 52 in transfer_memory_info() 46 dimm->ddr_frequency = dmi17->Speed; 47 dimm->rank_per_dimm = dmi17->Attributes; 48 dimm->mod_type = dmi17->MemoryType; 49 dimm->bus_width = dmi17->DataWidth; 50 dimm->mod_id = dmi17->ManufacturerIdCode; 51 dimm->bank_locator = 0; >>> CID 1387031: Memory - illegal accesses (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 19 bytes on destination array "dimm->module_part_number" of size 19 bytes might leave the destination string unterminated. 52 strncpy((char *)dimm->module_part_number, dmi17->PartNumber, 53 sizeof(dimm->module_part_number)); 54 } 55 56 static void prepare_dmi_17(void *unused) 57 { ** CID 1387030: (RESOURCE_LEAK) /3rdparty/chromeec/util/genvif.c: 520 in gen_vif() /3rdparty/chromeec/util/genvif.c: 550 in gen_vif() /3rdparty/chromeec/util/genvif.c: 550 in gen_vif() ________________________________________________________________________________________________________ *** CID 1387030: (RESOURCE_LEAK) /3rdparty/chromeec/util/genvif.c: 520 in gen_vif() 514 515 /* Write Source PDOs */ 516 for (i = 0; i < src_pdo_cnt; i++) { 517 pwr = write_pdo_to_buf(&buf, src_pdo[i], SRC, i+1); 518 if (pwr < 0) { 519 fprintf(stderr, "ERROR: Out of memory.\n"); >>> CID 1387030: (RESOURCE_LEAK) >>> Variable "vif" going out of scope leaks the storage it points to. 520 return 1; 521 } 522 523 if (pwr > max_power) 524 max_power = pwr; 525 } /3rdparty/chromeec/util/genvif.c: 550 in gen_vif() 544 /* Write Sink PDOs */ 545 for (i = 0; i < pd_snk_pdo_cnt; i++) { 546 pwr = write_pdo_to_buf(&buf, pd_snk_pdo[i], SNK, i+1); 547 548 if (pwr < 0) { 549 fprintf(stderr, "ERROR: Out of memory.\n"); >>> CID 1387030: (RESOURCE_LEAK) >>> Variable "vif" going out of scope leaks the storage it points to. 550 return 1; 551 } 552 553 if (pwr > max_power) 554 max_power = pwr; 555 } /3rdparty/chromeec/util/genvif.c: 550 in gen_vif() 544 /* Write Sink PDOs */ 545 for (i = 0; i < pd_snk_pdo_cnt; i++) { 546 pwr = write_pdo_to_buf(&buf, pd_snk_pdo[i], SNK, i+1); 547 548 if (pwr < 0) { 549 fprintf(stderr, "ERROR: Out of memory.\n"); >>> CID 1387030: (RESOURCE_LEAK) >>> Variable "vif" going out of scope leaks the storage it points to. 550 return 1; 551 } 552 553 if (pwr > max_power) 554 max_power = pwr; 555 } ** CID 1387029: (RESOURCE_LEAK) /3rdparty/chromeec/util/cbi-util.c: 192 in do_show() /3rdparty/chromeec/util/cbi-util.c: 197 in do_show() /3rdparty/chromeec/util/cbi-util.c: 201 in do_show() ________________________________________________________________________________________________________ *** CID 1387029: (RESOURCE_LEAK) /3rdparty/chromeec/util/cbi-util.c: 192 in do_show() 186 bi->major_version, bi->minor_version); 187 printf(" OEM_ID: %d (0x%02x)\n", bi->oem_id, bi->oem_id); 188 printf(" SKU_ID: %d (0x%02x)\n", bi->sku_id, bi->sku_id); 189 190 if (memcmp(bi->head.magic, cbi_magic, sizeof(cbi_magic))) { 191 fprintf(stderr, "Invalid Magic\n"); >>> CID 1387029: (RESOURCE_LEAK) >>> Variable "buf" going out of scope leaks the storage it points to. 192 return -1; 193 } 194 195 if (cbi_crc8(bi) != bi->head.crc) { 196 fprintf(stderr, "Invalid CRC\n"); 197 return -1; /3rdparty/chromeec/util/cbi-util.c: 197 in do_show() 191 fprintf(stderr, "Invalid Magic\n"); 192 return -1; 193 } 194 195 if (cbi_crc8(bi) != bi->head.crc) { 196 fprintf(stderr, "Invalid CRC\n"); >>> CID 1387029: (RESOURCE_LEAK) >>> Variable "buf" going out of scope leaks the storage it points to. 197 return -1; 198 } 199 200 printf("Data validated successfully\n"); 201 return 0; 202 } /3rdparty/chromeec/util/cbi-util.c: 201 in do_show() 195 if (cbi_crc8(bi) != bi->head.crc) { 196 fprintf(stderr, "Invalid CRC\n"); 197 return -1; 198 } 199 200 printf("Data validated successfully\n"); >>> CID 1387029: (RESOURCE_LEAK) >>> Variable "buf" going out of scope leaks the storage it points to. 201 return 0; 202 } 203 204 /* Print help and return error */ 205 static void print_help(int argc, char *argv[]) 206 { ** CID 1387028: Integer handling issues (BAD_SHIFT) /src/mainboard/google/poppy/variants/nami/memory.c: 70 in fill_ddr4_memory_params() ________________________________________________________________________________________________________ *** CID 1387028: Integer handling issues (BAD_SHIFT) /src/mainboard/google/poppy/variants/nami/memory.c: 70 in fill_ddr4_memory_params() 64 static void fill_ddr4_memory_params(struct memory_params *p) 65 { 66 p->type = MEMORY_DDR4; 67 p->use_sec_spd = 0; 68 69 /* Rcomp resistor values are different for SDP and DDP. */ >>> CID 1387028: Integer handling issues (BAD_SHIFT) >>> In expression "1 << variant_memory_sku() - 1", shifting by a negative amount has undefined behavior. The shift amount, "variant_memory_sku() - 1", is -1. 70 if (ddp_bitmap & MEM_ID(variant_memory_sku())) { 71 p->rcomp_resistor = rcomp_resistor_ddp; 72 p->rcomp_resistor_size = sizeof(rcomp_resistor_ddp); 73 } else { 74 p->rcomp_resistor = rcomp_resistor_sdp; 75 p->rcomp_resistor_size = sizeof(rcomp_resistor_sdp); ** CID 1387027: (RESOURCE_LEAK) /3rdparty/chromeec/util/cbi-util.c: 157 in do_create() /3rdparty/chromeec/util/cbi-util.c: 162 in do_create() ________________________________________________________________________________________________________ *** CID 1387027: (RESOURCE_LEAK) /3rdparty/chromeec/util/cbi-util.c: 157 in do_create() 151 memcpy(buf, bi, sizeof(*bi)); 152 153 /* Output blob */ 154 rv = write_file(cbi_filename, buf, size); 155 if (rv) { 156 fprintf(stderr, "Unable to write CBI blob\n"); >>> CID 1387027: (RESOURCE_LEAK) >>> Variable "buf" going out of scope leaks the storage it points to. 157 return rv; 158 } 159 160 fprintf(stderr, "CBI blob is created successfully\n"); 161 162 return 0; /3rdparty/chromeec/util/cbi-util.c: 162 in do_create() 156 fprintf(stderr, "Unable to write CBI blob\n"); 157 return rv; 158 } 159 160 fprintf(stderr, "CBI blob is created successfully\n"); 161 >>> CID 1387027: (RESOURCE_LEAK) >>> Variable "buf" going out of scope leaks the storage it points to. 162 return 0; 163 } 164 165 static int do_show(const char *cbi_filename, int show_all) 166 { 167 uint8_t *buf; ** CID 1384426: (FORWARD_NULL) /src/vendorcode/amd/agesa/common/amdlib.c: 444 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/PCENGINES_APU3/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/ODE_E21XX/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/GOOGLE_KAHLEE/libagesa/amdlib.c: 489 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/PCENGINES_APU5/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/AMD_DB_FT3B_LC/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/AMD_LAMAR/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/PCENGINES_APU2/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/PCENGINES_APU4/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/AMD_OLIVEHILLPLUS/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/GOOGLE_GRUNT/libagesa/amdlib.c: 489 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/AMD_BETTONG/libagesa/amdlib.c: 492 in LibAmdCLFlush() /dev/cb-build/coreboot-coverity.0/AMD_GARDENIA/libagesa/amdlib.c: 489 in LibAmdCLFlush() ________________________________________________________________________________________________________ *** CID 1384426: (FORWARD_NULL) /src/vendorcode/amd/agesa/common/amdlib.c: 444 in LibAmdCLFlush() 438 UINT8 *address32; 439 UINTN Index; 440 address32 = 0; 441 hwcrSave = SetFsBase (Address); 442 for (Index = 0; Index < Count; Index++){ 443 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 444 _mm_clflush_fs (&address32 [Index * 64]); 445 } 446 RestoreHwcr (hwcrSave); 447 } 448 #endif //__SSE3__ 449 /dev/cb-build/coreboot-coverity.0/PCENGINES_APU3/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/ODE_E21XX/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/GOOGLE_KAHLEE/libagesa/amdlib.c: 489 in LibAmdCLFlush() 483 UINT8 *address32; 484 UINTN Index; 485 address32 = 0; 486 hwcrSave = SetFsBase (Address); 487 for (Index = 0; Index < Count; Index++){ 488 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 489 _mm_clflush_fs (&address32 [Index * 64]); 490 } 491 RestoreHwcr (hwcrSave); 492 } 493 494 /dev/cb-build/coreboot-coverity.0/PCENGINES_APU5/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/AMD_DB_FT3B_LC/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/AMD_LAMAR/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/PCENGINES_APU2/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/PCENGINES_APU4/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/AMD_OLIVEHILLPLUS/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/GOOGLE_GRUNT/libagesa/amdlib.c: 489 in LibAmdCLFlush() 483 UINT8 *address32; 484 UINTN Index; 485 address32 = 0; 486 hwcrSave = SetFsBase (Address); 487 for (Index = 0; Index < Count; Index++){ 488 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 489 _mm_clflush_fs (&address32 [Index * 64]); 490 } 491 RestoreHwcr (hwcrSave); 492 } 493 494 /dev/cb-build/coreboot-coverity.0/AMD_BETTONG/libagesa/amdlib.c: 492 in LibAmdCLFlush() 486 UINT8 *address32; 487 UINTN Index; 488 address32 = 0; 489 hwcrSave = SetFsBase (Address); 490 for (Index = 0; Index < Count; Index++){ 491 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 492 _mm_clflush_fs (&address32 [Index * 64]); 493 } 494 RestoreHwcr (hwcrSave); 495 } 496 497 /dev/cb-build/coreboot-coverity.0/AMD_GARDENIA/libagesa/amdlib.c: 489 in LibAmdCLFlush() 483 UINT8 *address32; 484 UINTN Index; 485 address32 = 0; 486 hwcrSave = SetFsBase (Address); 487 for (Index = 0; Index < Count; Index++){ 488 _mm_mfence (); >>> CID 1384426: (FORWARD_NULL) >>> Dereferencing null pointer "address32". 489 _mm_clflush_fs (&address32 [Index * 64]); 490 } 491 RestoreHwcr (hwcrSave); 492 } 493 494 ** CID 1384425: Control flow issues (DEADCODE) /src/soc/intel/broadwell/pmutil.c: 371 in clear_gpe_status() ________________________________________________________________________________________________________ *** CID 1384425: Control flow issues (DEADCODE) /src/soc/intel/broadwell/pmutil.c: 371 in clear_gpe_status() 365 return gpe0_sts; 366 } 367 368 /* Clear all GPE status and return "standard" GPE event status */ 369 u32 clear_gpe_status(void) 370 { >>> CID 1384425: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "gpe0_sts_3_bits[gpe0_sts_3_...". 371 const char *gpe0_sts_3_bits[] = { 372 [1] = "HOTPLUG", 373 [2] = "SWGPE", 374 [6] = "TCO_SCI", 375 [7] = "SMB_WAK", 376 [9] = "PCI_EXP", ** CID 1384424: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 329 in gpio_input() ________________________________________________________________________________________________________ *** CID 1384424: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 329 in gpio_input() 323 struct pad_config cfg = PAD_CFG_GPI(gpio, UP_20K, DEEP); 324 gpio_configure_pad(&cfg); 325 } 326 327 void gpio_input(gpio_t gpio) 328 { >>> CID 1384424: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "cfg.pad_config[cfg@dim1] = 0U;". 329 struct pad_config cfg = PAD_CFG_GPI(gpio, NONE, DEEP); 330 gpio_configure_pad(&cfg); 331 } 332 333 void gpio_output(gpio_t gpio, int value) 334 { ** CID 1384423: Insecure data handling (TAINTED_SCALAR) /src/commonlib/fsp_relocate.c: 192 in te_relocate() ________________________________________________________________________________________________________ *** CID 1384423: Insecure data handling (TAINTED_SCALAR) /src/commonlib/fsp_relocate.c: 192 in te_relocate() 186 187 if (type == EFI_IMAGE_REL_BASED_HIGHLOW) { 188 uint32_t *reloc_addr; 189 uint32_t val; 190 191 offset += rva_offset; >>> CID 1384423: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "offset" as an index to pointer "te_base". 192 reloc_addr = (void *)&te_base[offset]; 193 val = read_le32(reloc_addr); 194 195 printk(FSP_DBG_LVL, "Adjusting %p %x -> %x\n", 196 reloc_addr, val, val + adj); 197 write_le32(reloc_addr, val + adj); ** CID 1384422: (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 158 in print_smi_status() /src/soc/intel/broadwell/pmutil.c: 151 in print_smi_status() ________________________________________________________________________________________________________ *** CID 1384422: (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 158 in print_smi_status() 152 return smi_sts; 153 } 154 155 /* Print SMI status bits */ 156 static u32 print_smi_status(u32 smi_sts) 157 { >>> CID 1384422: (DEADCODE) >>> Execution cannot reach this statement: "smi_sts_bits[smi_sts_bits@d...". 158 const char *smi_sts_bits[] = { 159 [2] = "BIOS", 160 [3] = "LEGACY_USB", 161 [4] = "SLP_SMI", 162 [5] = "APM", 163 [6] = "SWSMI_TMR", /src/soc/intel/broadwell/pmutil.c: 151 in print_smi_status() 145 return smi_sts; 146 } 147 148 /* Print SMI status bits */ 149 static u32 print_smi_status(u32 smi_sts) 150 { >>> CID 1384422: (DEADCODE) >>> Execution cannot reach this statement: "smi_sts_bits[smi_sts_bits@d...". 151 const char *smi_sts_bits[] = { 152 [2] = "BIOS", 153 [3] = "LEGACY_USB", 154 [4] = "SLP_SMI", 155 [5] = "APM", 156 [6] = "SWSMI_TMR", ** CID 1384421: (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 338 in print_tco_status() /src/soc/intel/broadwell/pmutil.c: 282 in print_tco_status() ________________________________________________________________________________________________________ *** CID 1384421: (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 338 in print_tco_status() 332 return tco_sts & tco_en; 333 } 334 335 /* Print TCO status bits */ 336 static u32 print_tco_status(u32 tco_sts) 337 { >>> CID 1384421: (DEADCODE) >>> Execution cannot reach this statement: "tco_sts_bits[tco_sts_bits@d...". 338 const char *tco_sts_bits[] = { 339 [0] = "NMI2SMI", 340 [1] = "SW_TCO", 341 [2] = "TCO_INT", 342 [3] = "TIMEOUT", 343 [7] = "NEWCENTURY", /src/soc/intel/broadwell/pmutil.c: 282 in print_tco_status() 276 return tco_sts & tco_en; 277 } 278 279 /* Print TCO status bits */ 280 static u32 print_tco_status(u32 tco_sts) 281 { >>> CID 1384421: (DEADCODE) >>> Execution cannot reach this statement: "tco_sts_bits[tco_sts_bits@d...". 282 const char *tco_sts_bits[] = { 283 [0] = "NMI2SMI", 284 [1] = "SW_TCO", 285 [2] = "TCO_INT", 286 [3] = "TIMEOUT", 287 [7] = "NEWCENTURY", ** CID 1384420: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 335 in gpio_output() ________________________________________________________________________________________________________ *** CID 1384420: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 335 in gpio_output() 329 struct pad_config cfg = PAD_CFG_GPI(gpio, NONE, DEEP); 330 gpio_configure_pad(&cfg); 331 } 332 333 void gpio_output(gpio_t gpio, int value) 334 { >>> CID 1384420: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "cfg.pad_config[cfg@dim1] = 0U;". 335 struct pad_config cfg = PAD_CFG_GPO(gpio, value, DEEP); 336 gpio_configure_pad(&cfg); 337 } 338 339 int gpio_get(gpio_t gpio_num) 340 { ** CID 1384419: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 323 in gpio_input_pullup() ________________________________________________________________________________________________________ *** CID 1384419: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 323 in gpio_input_pullup() 317 struct pad_config cfg = PAD_CFG_GPI(gpio, DN_20K, DEEP); 318 gpio_configure_pad(&cfg); 319 } 320 321 void gpio_input_pullup(gpio_t gpio) 322 { >>> CID 1384419: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "cfg.pad_config[cfg@dim1] = 0U;". 323 struct pad_config cfg = PAD_CFG_GPI(gpio, UP_20K, DEEP); 324 gpio_configure_pad(&cfg); 325 } 326 327 void gpio_input(gpio_t gpio) 328 { ** CID 1384418: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1384418: Memory - corruptions (OVERRUN) /src/soc/mediatek/mt8173/i2c.c: 327 in platform_i2c_transfer() 321 { 322 int ret = 0; 323 int i; 324 int read; 325 326 for (i = 0; i < seg_count; i++) { >>> CID 1384418: Memory - corruptions (OVERRUN) >>> Overrunning struct type i2c_msg of 16 bytes by passing it to a function which accesses it at byte offset 16. 327 if (mtk_i2c_should_combine(&segments[i], seg_count - i)) { 328 read = I2C_WRITE_READ_MODE; 329 } else { 330 read = (segments[i].flags & I2C_M_RD) ? 331 I2C_READ_MODE : I2C_WRITE_MODE; 332 } ** CID 1384417: (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 429 in clear_lpt_gpe_status() /src/southbridge/intel/lynxpoint/pmutil.c: 456 in clear_lpt_gpe_status() ________________________________________________________________________________________________________ *** CID 1384417: (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 429 in clear_lpt_gpe_status() 423 return gpe0_sts; 424 } 425 426 /* Print, clear, and return LynxPoint-H GPE0 status */ 427 static u32 clear_lpt_gpe_status(void) 428 { >>> CID 1384417: (DEADCODE) >>> Execution cannot reach this statement: "gpe0_sts_bits_low[gpe0_sts_...". 429 const char *gpe0_sts_bits_low[] = { 430 [1] = "HOTPLUG", 431 [2] = "SWGPE", 432 [6] = "TCO_SCI", 433 [7] = "SMB_WAK", 434 [8] = "RI", /src/southbridge/intel/lynxpoint/pmutil.c: 456 in clear_lpt_gpe_status() 450 [27] = "GPIO11", 451 [28] = "GPIO12", 452 [29] = "GPIO13", 453 [30] = "GPIO14", 454 [31] = "GPIO15", 455 }; >>> CID 1384417: (DEADCODE) >>> Execution cannot reach this statement: "gpe0_sts_bits_high[gpe0_sts...". 456 const char *gpe0_sts_bits_high[] = { 457 [3] = "GPIO27", 458 [6] = "WADT", 459 [24] = "GPIO17", 460 [25] = "GPIO19", 461 [26] = "GPIO21", ** CID 1384416: (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 109 in print_pm1_status() /src/soc/intel/broadwell/pmutil.c: 102 in print_pm1_status() ________________________________________________________________________________________________________ *** CID 1384416: (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 109 in print_pm1_status() 103 return pm1_sts; 104 } 105 106 /* Print PM1 status bits */ 107 static u16 print_pm1_status(u16 pm1_sts) 108 { >>> CID 1384416: (DEADCODE) >>> Execution cannot reach this statement: "pm1_sts_bits[pm1_sts_bits@d...". 109 const char *pm1_sts_bits[] = { 110 [0] = "TMROF", 111 [4] = "BM", 112 [5] = "GBL", 113 [8] = "PWRBTN", 114 [10] = "RTC", /src/soc/intel/broadwell/pmutil.c: 102 in print_pm1_status() 96 return pm1_sts; 97 } 98 99 /* Print PM1 status bits */ 100 static u16 print_pm1_status(u16 pm1_sts) 101 { >>> CID 1384416: (DEADCODE) >>> Execution cannot reach this statement: "pm1_sts_bits[pm1_sts_bits@d...". 102 const char *pm1_sts_bits[] = { 103 [0] = "TMROF", 104 [4] = "BM", 105 [5] = "GBL", 106 [8] = "PWRBTN", 107 [10] = "RTC", ** CID 1384415: Control flow issues (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 481 in clear_lpt_lp_gpe_status() ________________________________________________________________________________________________________ *** CID 1384415: Control flow issues (DEADCODE) /src/southbridge/intel/lynxpoint/pmutil.c: 481 in clear_lpt_lp_gpe_status() 475 gpe0_sts_bits_low); 476 } 477 478 /* Print, clear, and return LynxPoint-LP GPE0 status */ 479 static u32 clear_lpt_lp_gpe_status(void) 480 { >>> CID 1384415: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "gpe0_sts_4_bits[gpe0_sts_4_...". 481 const char *gpe0_sts_4_bits[] = { 482 [1] = "HOTPLUG", 483 [2] = "SWGPE", 484 [6] = "TCO_SCI", 485 [7] = "SMB_WAK", 486 [9] = "PCI_EXP", ** CID 1384414: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 317 in gpio_input_pulldown() ________________________________________________________________________________________________________ *** CID 1384414: Control flow issues (DEADCODE) /src/soc/intel/common/block/gpio/gpio.c: 317 in gpio_input_pulldown() 311 const struct pad_community *comm = gpio_get_community(pad); 312 return comm->port; 313 } 314 315 void gpio_input_pulldown(gpio_t gpio) 316 { >>> CID 1384414: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "cfg.pad_config[cfg@dim1] = 0U;". 317 struct pad_config cfg = PAD_CFG_GPI(gpio, DN_20K, DEEP); 318 gpio_configure_pad(&cfg); 319 } 320 321 void gpio_input_pullup(gpio_t gpio) 322 { ** CID 1353116: Control flow issues (DEADCODE) /3rdparty/chromeec/chip/stm32/usb_pd_phy.c: 650 in pd_hw_init() ________________________________________________________________________________________________________ *** CID 1353116: Control flow issues (DEADCODE) /3rdparty/chromeec/chip/stm32/usb_pd_phy.c: 650 in pd_hw_init() 644 val = (6 << 4) | (1 << 3); 645 if ((TIM_TX_CCR_IDX(port) & 1) == 0) /* CH2 or CH4 */ 646 val <<= 8; 647 if (TIM_TX_CCR_IDX(port) <= 2) 648 phy->tim_tx->ccmr1 = val; 649 else >>> CID 1353116: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "phy->tim_tx->ccmr2 = val;". 650 phy->tim_tx->ccmr2 = val; 651 phy->tim_tx->ccer = 1 << ((TIM_TX_CCR_IDX(port) - 1) * 4); 652 phy->tim_tx->bdtr = 0x8000; 653 /* set prescaler to /1 */ 654 phy->tim_tx->psc = 0; 655 /* Reload the pre-scaler and reset the counter */ ** CID 1353115: Control flow issues (DEADCODE) /3rdparty/chromeec/chip/stm32/usb_pd_phy.c: 539 in pd_hw_init_rx() ________________________________________________________________________________________________________ *** CID 1353115: Control flow issues (DEADCODE) /3rdparty/chromeec/chip/stm32/usb_pd_phy.c: 539 in pd_hw_init_rx() 533 534 /* Timeout for message receive */ 535 phy->tim_rx->ccr[2] = (2400000 / 1000) * USB_PD_RX_TMOUT_US / 1000; 536 /* Timer ICx input configuration */ 537 if (TIM_RX_CCR_IDX(port) == 1) 538 phy->tim_rx->ccmr1 |= TIM_CCR_CS << 0; >>> CID 1353115: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "if ((port ? 1 : 1) == 2) ...". 539 else if (TIM_RX_CCR_IDX(port) == 2) 540 phy->tim_rx->ccmr1 |= TIM_CCR_CS << 8; 541 else if (TIM_RX_CCR_IDX(port) == 4) 542 phy->tim_rx->ccmr2 |= TIM_CCR_CS << 8; 543 else 544 /* Unsupported RX timer capture input */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] Server systems shipped with coreboot
by Timothy Pearson March 23, 2018

March 23, 2018

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 4 cores, SMT4. There's an 8-core available for $190 more, and AFAIK there are plans to start offering an 18-core server chip very shortly. These are the OpenPOWER machines, so there is hardware virtualization support (including I/O passthrough) that works well with kvm and QEMU. I haven't really heard anything referred to as "LPAR" on these newer POWER8/POWER9 machines outside of legacy documents. On 01/23/2018 12:47 PM, ron minnich wrote: > how many cores is that? Does it come with LPAR? > > On Mon, Jan 22, 2018 at 9:48 PM Taiidan(a)gmx.com <mailto:Taiidan@gmx.com> > <Taiidan(a)gmx.com <mailto:Taiidan@gmx.com>> wrote: > > In case anyone wants to know the (non-coreboot) libre firmware TALOS 2 > single CPU/board combo is now only 2.5K. > > I still can't figure out how they managed to make it so affordable, this > is seriously great. > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > https://mail.coreboot.org/mailman/listinfo/coreboot > - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJaZ4U2AAoJEK+E3vEXDOFbBUEIAKxL6cD2L27yZh63OhM0TD8h BZD2r0nYF/NLfGi50KuMZPNzb2lpzgLHc06ZHZmJBU0sFUbTdI3WrYibDPtY4lva 1uG3gedN2u+sUCzTKrLILOyrstlJ2lQ4+8jxyO8PncK9Zx3LtgbSlGVGq+pvxsXI Ac8Yqm+de6Is8aaAHMMzaT9UNxcjXCAs/zZm3iWcPkA2B0CVVUoKnsFuhtGG1cGd j4bukGJrojkUMEFxIG93qphcurdP2AjuvOaUdZVuoC0uxdVL2az77SgRUH8Vmxdd SFhAzG7j4LsqGMwiZBkubBZpSMPj6kPyRQUIxwwAk/vRLpOxoPdaEbrI/9wyIaM= =PFaf -----END PGP SIGNATURE-----

2 1

[Broadwell] Why does refcode disable EHCI
by Zheng Bao March 23, 2018

March 23, 2018

On my board with broadwell, the EHCI controller is disable after refcode runs. RCBA(FD) is 1. After refcode, RCBA(FD) is 0x8001. So I doubt the PEI data is not filled correctly. I change all ports like this. pei_data_usb2_port(pei_data, 0, 0x0080, 1, USB_OC_PIN_SKIP, //1, USB_PORT_BACK_PANEL); But it still does not work. The refcode is extracted from SAMUS board shell ball. Anybody has an idea? Thanks. Zheng

1 0

Minnowboard
by Daniel Wagner March 22, 2018

March 22, 2018

Hi, I would like to test my -rt kernels releases on the minnowboard. Though cyclictest always reports 2 to 4 ms spikes. It looks like that the original firmware is stealing those cycles. So my plan was to try out coreboot and see if my theory is correct or not. Now, I am struggling with getting anything working. All my attempts to bake a working binary have been completely fruitless. Not a single char on the serial port. If I would at least get something on the serial port I could find my way through the maze. I am confident that flashing the device is works correctly via my raspberry pi [2]. When I flash the original firmware, the device comes back to live again. Unfortunately, the documentation on how to configure and build coreboot a bit outdated [1]. My google-foo didn't help either. Could someone share his/her current config and also post the SHAs of coreboot? This would rule out that part. I am not sure if my binary blobs I extracted or downloaded are okay (fd, me, gbe, FSB). Thanks, Daniel [1] https://elinux.org/Minnowboard:MinnowMaxCoreboot [2] https://3mdeb.com/firmware/flashing-minnowboard-turbot-with-raspberry-pi-ze…

3 7

Re: [coreboot] Minnowboard
by Daniel Wagner March 22, 2018

March 22, 2018

Hi Michael and Zoran, On 03/22/2018 08:45 PM, Zoran Stojsavljevic wrote: > IIRC, there are two types of BYT-i used for IOTG, in INTEL. The CPUIDs > are 0x30673 (for Revision B) and 0x30679 (for Revision D). You can > retrieve CPUID using simplistic CLI: dmesg | grep microcode after > bringing Linux up: root@mb:~# dmesg | grep microcode [ 3.332005] microcode: CPU0 sig=0x30679, pf=0x1, revision=0x906 [ 3.332024] microcode: CPU1 sig=0x30679, pf=0x1, revision=0x906 >> What type of Minnowboard do you use? dmidecode says: System Information Manufacturer: ADI Product Name: Minnowboard Turbot D0 PLATFORM Version: D0 >> First thing is to make sure the microcode is right without that it will hang >> before giving any output. As suggested by Piotr, I just flashed the the bios section of the flash and now I get some serial output. That seems not suprising because I went back and took the BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd FSP. Thanks, Daniel

1 0

Re: [coreboot] Minnowboard
by Zoran Stojsavljevic March 22, 2018

March 22, 2018

> First thing is to make sure the microcode is right without that it will hang before giving any output. IIRC, there are two types of BYT-i used for IOTG, in INTEL. The CPUIDs are 0x30673 (for Revision B) and 0x30679 (for Revision D). You can retrieve CPUID using simplistic CLI: dmesg | grep microcode after bringing Linux up: [vuser@localhost ~]$ dmesg | grep microcode [ 0.000000] Intel Spectre v2 broken microcode detected; disabling Speculation Control [ 3.796088] microcode: sig=0x40651, pf=0x40, revision=0x21 [ 3.796202] microcode: Microcode Update Driver: v2.2. [vuser@localhost ~]$ Daniel, I suggest to you to put/flash original BYT-I BIOS back and read from CMOS the CPUID and MCU numbers. Then you'll know exactly what ingredients you'll need for Coreboot. Here are some MCU numbers for BYT-I CPUIDs: 0x30673 (Rev. B) and 0x30679 (Rev. D): https://lists.denx.de/pipermail/u-boot/2016-May/255536.html Best Regards, Zoran _______ On Thu, Mar 22, 2018 at 6:47 PM, Michael Graichen <michael.graichen(a)hotmail.com> wrote: > Hey Daniel, > > What type of Minnowboard do you use? > > First thing is to make sure the microcode is right without that it will hang > before giving any output. > > Best regards > Michael > > > > > > -------- Ursprüngliche Nachricht -------- > Von: Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> > Datum: 21.03.18 13:23 (GMT+01:00) > An: Daniel Wagner <wagi(a)monom.org> > Cc: coreboot <coreboot(a)coreboot.org> > Betreff: Re: [coreboot] Minnowboard > > Hello Daniel, > > You need to properly build Coreboot, integrating BYT-I (as I recall > minnow board) FSP, and the info about BYT-I FSP you can find here: > https://github.com/IntelFsp/FSP > > Zoran > _______ > > On Wed, Mar 21, 2018 at 12:47 PM, Daniel Wagner <wagi(a)monom.org> wrote: >> Hi, >> >> I would like to test my -rt kernels releases on the minnowboard. Though >> cyclictest always reports 2 to 4 ms spikes. It looks like that the >> original firmware is stealing those cycles. So my plan was to try out >> coreboot and see if my theory is correct or not. >> >> Now, I am struggling with getting anything working. All my attempts to >> bake a working binary have been completely fruitless. Not a single char >> on the serial port. If I would at least get something on the serial port >> I could find my way through the maze. >> >> I am confident that flashing the device is works correctly via my >> raspberry pi [2]. When I flash the original firmware, the device comes >> back to live again. >> >> Unfortunately, the documentation on how to configure and build coreboot >> a bit outdated [1]. My google-foo didn't help either. >> >> Could someone share his/her current config and also post the SHAs of >> coreboot? This would rule out that part. I am not sure if my binary >> blobs I extracted or downloaded are okay (fd, me, gbe, FSB). >> >> Thanks, >> Daniel >> >> [1] https://elinux.org/Minnowboard:MinnowMaxCoreboot >> [2] >> >> https://3mdeb.com/firmware/flashing-minnowboard-turbot-with-raspberry-pi-ze… >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Minnowboard
by Michael Graichen March 22, 2018

March 22, 2018

Hey Daniel, What type of Minnowboard do you use? First thing is to make sure the microcode is right without that it will hang before giving any output. Best regards Michael -------- Ursprüngliche Nachricht -------- Von: Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> Datum: 21.03.18 13:23 (GMT+01:00) An: Daniel Wagner <wagi(a)monom.org> Cc: coreboot <coreboot(a)coreboot.org> Betreff: Re: [coreboot] Minnowboard Hello Daniel, You need to properly build Coreboot, integrating BYT-I (as I recall minnow board) FSP, and the info about BYT-I FSP you can find here: https://github.com/IntelFsp/FSP Zoran _______ On Wed, Mar 21, 2018 at 12:47 PM, Daniel Wagner <wagi(a)monom.org> wrote: > Hi, > > I would like to test my -rt kernels releases on the minnowboard. Though > cyclictest always reports 2 to 4 ms spikes. It looks like that the > original firmware is stealing those cycles. So my plan was to try out > coreboot and see if my theory is correct or not. > > Now, I am struggling with getting anything working. All my attempts to > bake a working binary have been completely fruitless. Not a single char > on the serial port. If I would at least get something on the serial port > I could find my way through the maze. > > I am confident that flashing the device is works correctly via my > raspberry pi [2]. When I flash the original firmware, the device comes > back to live again. > > Unfortunately, the documentation on how to configure and build coreboot > a bit outdated [1]. My google-foo didn't help either. > > Could someone share his/her current config and also post the SHAs of > coreboot? This would rule out that part. I am not sure if my binary > blobs I extracted or downloaded are okay (fd, me, gbe, FSB). > > Thanks, > Daniel > > [1] https://elinux.org/Minnowboard:MinnowMaxCoreboot > [2] > https://3mdeb.com/firmware/flashing-minnowboard-turbot-with-raspberry-pi-ze… > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Interrupt routing with PCIe bridges as many functions of one southbridge device
by Аладышев Константин March 21, 2018

March 21, 2018

Hello! I'm working with Haswell+Lynxpoint chip and it has 6 PCIe bridges presented on one southbridge device "1c" as six functions (I mean "1c.0", "1c.1", ..., "1c.5"). As I understand, every function (bridge in this example) can drive only one INTX line of its "1c" device. For example, function 1c.2 can drive only INTC of "1c" device. Does it mean that every device behind 1c.2 PCIe bridge should connect all of its INTA-D lines to INTC of 1c.2 in order to work? (by "connect" I mean declare interrupt routing in ACPI/MP table/PIRQ table) Best Regards, Aladyshev Konstantin

1 0

Microcode updates for slightly older intel CPU's re: meltdown/spectre
by Taiidan＠gmx.com March 21, 2018

March 21, 2018

I am curious of any intel insiders know if there will be microcode updates released for older intel CPU's (ex: sandy/ivybridge) and failing that, what can be done in regards to securing them from meltdown/spectre. I believe this is a relevant coreboot topic considering how many coreboot boards have these and older CPU's....without a fix there will be only one coreboot compatible laptop with open source hardware initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD CPU) and theoretically owner controllable (as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently) At this point even a massive performance loss is better than having to throw out so much now-useless hardware.

10 20

[RFH] Please upload board status for your board
by Paul Menzel March 21, 2018

March 21, 2018

Dear coreboot folks, I’d be great, if you took a few minutes to upload the status of your board to the board status repository [1]. Please make sure, that in the coreboot repository `git describe -- dirty` doesn’t return a string with *dirty* in it. Often it is caused by changes in the directory `3rdparty`, which you can fix by running `make gitconfig` and `git sup`. Please also make sure to configure at least a valid email address in git, so in case of questions you can be contacted. Note, SeaBIOS master is currently broken, meaning that, there are huge delays if a TPM chip is not found [2]. So, please stay with 1.11.0 or 1.11.1 until the patches [3] are added to SeaBIOS’ master branch. Thank you for your help, Paul PS: I am aware, that the board status script needs to be made more user friendly, but as long as nobody has time to improve it, it’s what we have. [1] util/board_status/README [2] https://mail.coreboot.org/pipermail/seabios/2018-March/012191.html [3] https://mail.coreboot.org/pipermail/seabios/2018-March/012223.html

2 1