coreboot September 2016

coreboot@coreboot.org

51 participants
82 discussions

Re: [coreboot] weird problem with KGPE-D16
by ron minnich 14 Sep '16

14 Sep '16

I did a bit more digging. With this change, the trampoline code changed too. I have no idea why linux payloads work for anyone past this ref. It may just be you get the right config options and get lucky. The bigger problem is lots of us took the bzimage format as constant, in some sense, and it's clearly possible for it to change in ways that break coreboot (and u-boot, in this case, and an arm chromebook as you can see from the discussion). good times. tpearson and Tram, are you running with CONFIG_RELOCATABLE? I expect Tram has to be, since he uses kexec. tpearson? Because the coreboot trampoline makes assumptions that don't work with CONFIG_RELOCATABLE AFAICT. Overall, a problem I see is that the coreboot trampoline code is built with the assumption that a trampoline can function apart from the kernel, i.e. that there is indepedence. I don't believe that is true any more. See this in newer 4.x linuxes: #ifdef CONFIG_RELOCATABLE i.e. the trampoline code is now parameterized by the configuration. Our trampoline assumes the kernel starts at 0x100000. I think the fix will be to remove the coreboot trampolilne code for bzimage and extract the needed trampoline code from the bzimage. I'll try that. ron On Tue, Sep 13, 2016 at 4:43 PM ron minnich <rminnich(a)gmail.com> wrote: > I've been trying to find a problem in linux that makes it not boot when > used as the payload in the KGPE-D16. The symptom is that I get no output at > all on serial when linux starts. > > I finally got it down to 1 commit today in linux. > > commit 974f221c84b05b1dc2f5ea50dc16d2a9d1e95eda > Author: Yinghai Lu <yinghai(a)kernel.org> > Date: Thu Apr 28 17:09:04 2016 -0700 > > x86/boot: Move compressed kernel to the end of the decompression buffer > > If I build a linux kernel up to but not including this commit, all is > well. If I build with this commit, Linux is silent -- no serial output. > > Anyway, I will be looking at this, but if you have solved it let me know. > > thanks > > ron >

1 0

Proposal for new "Commenting" wiki text (was: [RFC] Deciding on style for multi-line comments)
by Nico Huber 14 Sep '16

14 Sep '16

Hi folks, I think we kind of agreed that the wiki text about "Commenting" should change. So here is my proposal, feel free to edit, add something or just ack or complain about it. > == Commenting == > > Comments are good, but there is also a danger of over-commenting. NEVER > try to explain HOW your code works in a comment: it's much better to > write the code so that the _working_ is obvious, and it's a waste of > time to explain badly written code. > > Generally, you want your comments to tell WHAT your code does, not HOW. > Also, try to avoid complex comments inside a function body: if the > function is so complex that you need to separately comment parts of it, > you should probably go back to chapter 6 for a while. You can make > small comments to note or warn about something particularly clever (or > ugly), but try to avoid excess. Instead, put the comments at the head > of the function, telling people what it does, and possibly WHY it does > it. > > coreboot style for comments is the C89 "/* ... */" style. You may also > use C99-style "// ..." comments. > > The preferred style for concise multi-line comments that explain a > single piece of code is: > > /* This is the preferred style for > shorter multi-line comments that > avoids excessive blank lines. */ > > Note that there shouldn't be leading asterisks on new lines in the > concise style. > > The preferred style for long multi-line comments is: > > /* > * This is the preferred style for multi-line > * comments in the coreboot source code. > * > * Description: A column of asterisks on the left side, > * with beginning and ending almost-blank lines. > */ > > Some rules of thumb to decide which style to use: > * If you are commenting a whole function (indentation level 0) or > something high level (indentation level 1), use the long style. > * If you want to explain a single piece of code and your comment > doesn't span multiple paragraphs, use the concise style. > * Otherwise you might want to ask yourself why what you're going to > explain doesn't deserve an own function. > > It's also important to comment data, whether they are basic types or > derived types. To this end, use just one data declaration per line (no > commas for multiple data declarations). This leaves you room for a > small comment on each item, explaining its use. > > In case of doubt, the author of the code shall have the last word on > comment styles. He should know best which style makes his code most > readable. Nico

4 3

Re: [coreboot] weird problem with KGPE-D16
by Aaron Durbin 14 Sep '16

14 Sep '16

On Tue, Sep 13, 2016 at 6:43 PM, ron minnich <rminnich(a)gmail.com> wrote: > I've been trying to find a problem in linux that makes it not boot when used > as the payload in the KGPE-D16. The symptom is that I get no output at all > on serial when linux starts. > > I finally got it down to 1 commit today in linux. > > commit 974f221c84b05b1dc2f5ea50dc16d2a9d1e95eda > Author: Yinghai Lu <yinghai(a)kernel.org> > Date: Thu Apr 28 17:09:04 2016 -0700 > > x86/boot: Move compressed kernel to the end of the decompression buffer > > If I build a linux kernel up to but not including this commit, all is well. > If I build with this commit, Linux is silent -- no serial output. Does it still boot (just no serial) ? > > Anyway, I will be looking at this, but if you have solved it let me know. > > thanks > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] weird problem with KGPE-D16
by Trammell Hudson 14 Sep '16

14 Sep '16

On Tue, Sep 13, 2016 at 11:43:08PM +0000, ron minnich wrote: > I've been trying to find a problem in linux that makes it not boot when > used as the payload in the KGPE-D16. The symptom is that I get no output at > all on serial when linux starts. That sounds related to the decompression problem that I encountered: https://www.coreboot.org/pipermail/coreboot/2016-August/081891.html Luckily I was able to reproduce it in qemu, but not fix it other than patching the Linux x86/boot code. -- Trammell

1 0

weird problem with KGPE-D16
by ron minnich 14 Sep '16

14 Sep '16

I've been trying to find a problem in linux that makes it not boot when used as the payload in the KGPE-D16. The symptom is that I get no output at all on serial when linux starts. I finally got it down to 1 commit today in linux. commit 974f221c84b05b1dc2f5ea50dc16d2a9d1e95eda Author: Yinghai Lu <yinghai(a)kernel.org> Date: Thu Apr 28 17:09:04 2016 -0700 x86/boot: Move compressed kernel to the end of the decompression buffer If I build a linux kernel up to but not including this commit, all is well. If I build with this commit, Linux is silent -- no serial output. Anyway, I will be looking at this, but if you have solved it let me know. thanks ron

1 0

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

13 Sep '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 46 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 20 of 46 defect(s) ** CID 1361275: (TAINTED_SCALAR) /util/cbfstool/ifwitool.c: 838 in parse_subpart_dir() ________________________________________________________________________________________________________ *** CID 1361275: (TAINTED_SCALAR) /util/cbfstool/ifwitool.c: 831 in parse_subpart_dir() 825 memcpy(hdr.name, data + offset, sizeof(hdr.name)); 826 offset += sizeof(hdr.name); 827 828 validate_subpart_dir_without_checksum((struct subpart_dir *)&hdr, name); 829 830 assert(size > subpart_dir_size(&hdr)); >>> CID 1361275: (TAINTED_SCALAR) >>> Passing tainted variable "subpart_dir_size(&hdr)" to a tainted sink. 831 alloc_buffer(subpart_dir_buf, subpart_dir_size(&hdr), "Subpart Dir"); 832 memcpy(buffer_get(subpart_dir_buf), &hdr, SUBPART_DIR_HEADER_SIZE); 833 834 /* Read Subpart Dir entries. */ 835 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf); 836 struct subpart_dir_entry *e = &subpart_dir->e[0]; /util/cbfstool/ifwitool.c: 838 in parse_subpart_dir() 832 memcpy(buffer_get(subpart_dir_buf), &hdr, SUBPART_DIR_HEADER_SIZE); 833 834 /* Read Subpart Dir entries. */ 835 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf); 836 struct subpart_dir_entry *e = &subpart_dir->e[0]; 837 uint32_t i; >>> CID 1361275: (TAINTED_SCALAR) >>> Using tainted variable "hdr.num_entries" as a loop boundary. 838 for (i = 0; i < hdr.num_entries; i++) { 839 memcpy(e[i].name, data + offset, sizeof(e[i].name)); 840 offset += sizeof(e[i].name); 841 offset = read_member(data, offset, sizeof(e[i].offset), 842 &e[i].offset); 843 offset = read_member(data, offset, sizeof(e[i].length), ** CID 1361274: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1361274: Insecure data handling (TAINTED_SCALAR) /util/cbfstool/ifwitool.c: 717 in alloc_bpdt_buffer() 711 { 712 struct bpdt_header bpdt_header; 713 assert((offset + BPDT_HEADER_SIZE) < size); 714 bpdt_read_header((uint8_t *)data + offset, &bpdt_header, name); 715 716 /* Buffer to read BPDT header and entries. */ >>> CID 1361274: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "get_bpdt_size(&bpdt_header)" to a tainted sink. 717 alloc_buffer(b, get_bpdt_size(&bpdt_header), name); 718 719 struct bpdt *bpdt = buffer_get(b); 720 memcpy(&bpdt->h, &bpdt_header, BPDT_HEADER_SIZE); 721 722 /* ** CID 1361253: Memory - illegal accesses (BUFFER_SIZE_WARNING) /util/cbfstool/ifwitool.c: 1300 in init_subpart_dir_entry() ________________________________________________________________________________________________________ *** CID 1361253: Memory - illegal accesses (BUFFER_SIZE_WARNING) /util/cbfstool/ifwitool.c: 1300 in init_subpart_dir_entry() 1294 static size_t init_subpart_dir_entry(struct subpart_dir_entry *e, 1295 struct buffer *b, size_t offset) 1296 { 1297 memset(e, 0, sizeof(*e)); 1298 1299 assert(strlen(b->name) <= sizeof(e->name)); >>> CID 1361253: Memory - illegal accesses (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 12 bytes on destination array "e->name" of size 12 bytes might leave the destination string unterminated. 1300 strncpy((char *)e->name, (char *)b->name, sizeof(e->name)); 1301 e->offset = offset; 1302 e->length = buffer_size(b); 1303 1304 return (offset + buffer_size(b)); 1305 } ** CID 1353793: Resource leaks (RESOURCE_LEAK) /util/nvidia/cbootimage/src/data_layout.c: 1096 in resign_bl() ________________________________________________________________________________________________________ *** CID 1353793: Resource leaks (RESOURCE_LEAK) /util/nvidia/cbootimage/src/data_layout.c: 1096 in resign_bl() 1090 1091 if (read_from_image(context->input_image_filename, 1092 offset, bl_length, 1093 &image, &image_actual_size, file_type_bin)) { 1094 printf("Error reading image file %s.\n", 1095 context->input_image_filename); >>> CID 1353793: Resource leaks (RESOURCE_LEAK) >>> Variable "image" going out of scope leaks the storage it points to. 1096 return -ENOMEM; 1097 } 1098 1099 pages_in_image = ICEIL(image_actual_size, page_size); 1100 1101 /* Create a local copy of the bl */ ** CID 1353781: Control flow issues (NO_EFFECT) /util/nvidia/cbootimage/src/cbootimage.c: 242 in main() ________________________________________________________________________________________________________ *** CID 1353781: Control flow issues (NO_EFFECT) /util/nvidia/cbootimage/src/cbootimage.c: 242 in main() 236 context.input_image_filename); 237 goto fail; 238 } 239 240 /* Get BCT_SIZE from input image file */ 241 bct_size = get_bct_size_from_image(&context); >>> CID 1353781: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "bct_size < 0U". 242 if (bct_size < 0) { 243 printf("Error: Invalid input image file %s\n", 244 context.input_image_filename); 245 goto fail; 246 } 247 ** CID 1353028: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 284 in integrate_psp_firmwares() ________________________________________________________________________________________________________ *** CID 1353028: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 284 in integrate_psp_firmwares() 278 pspdir[4+4*i+2] = 1; 279 pspdir[4+4*i+3] = 0; 280 } else if (fw_table[i].filename != NULL) { 281 pspdir[4+4*i+0] = fw_table[i].type; 282 283 fd = open (fw_table[i].filename, O_RDONLY); >>> CID 1353028: Error handling issues (NEGATIVE_RETURNS) >>> "fd" is passed to a parameter that cannot be negative. [Note: The source code implementation of the function has been overridden by a builtin model.] 284 fstat(fd, &fd_stat); 285 pspdir[4+4*i+1] = fd_stat.st_size; 286 287 pspdir[4+4*i+2] = pos + ROM_BASE_ADDRESS; 288 pspdir[4+4*i+3] = 0; 289 ** CID 1353027: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 239 in integrate_firmwares() ________________________________________________________________________________________________________ *** CID 1353027: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 239 in integrate_firmwares() 233 struct stat fd_stat; 234 int i; 235 236 for (i = 0; fw_table[i].type != AMD_FW_INVALID; i ++) { 237 if (fw_table[i].filename != NULL) { 238 fd = open (fw_table[i].filename, O_RDONLY); >>> CID 1353027: Error handling issues (NEGATIVE_RETURNS) >>> "fd" is passed to a parameter that cannot be negative. [Note: The source code implementation of the function has been overridden by a builtin model.] 239 fstat(fd, &fd_stat); 240 241 switch (fw_table[i].type) { 242 case AMD_FW_IMC: 243 pos = ALIGN(pos, 0x10000); 244 romsig[1] = pos + ROM_BASE_ADDRESS; ** CID 1353021: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 290 in integrate_psp_firmwares() ________________________________________________________________________________________________________ *** CID 1353021: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 290 in integrate_psp_firmwares() 284 fstat(fd, &fd_stat); 285 pspdir[4+4*i+1] = fd_stat.st_size; 286 287 pspdir[4+4*i+2] = pos + ROM_BASE_ADDRESS; 288 pspdir[4+4*i+3] = 0; 289 >>> CID 1353021: Error handling issues (CHECKED_RETURN) >>> "read(int, void *, size_t)" returns the number of bytes read, but it is ignored. 290 read (fd, base+pos, fd_stat.st_size); 291 292 pos += fd_stat.st_size; 293 pos = ALIGN(pos, 0x100); 294 close (fd); 295 } else { ** CID 1353020: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 284 in integrate_psp_firmwares() ________________________________________________________________________________________________________ *** CID 1353020: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 284 in integrate_psp_firmwares() 278 pspdir[4+4*i+2] = 1; 279 pspdir[4+4*i+3] = 0; 280 } else if (fw_table[i].filename != NULL) { 281 pspdir[4+4*i+0] = fw_table[i].type; 282 283 fd = open (fw_table[i].filename, O_RDONLY); >>> CID 1353020: Error handling issues (CHECKED_RETURN) >>> Calling "fstat(fd, &fd_stat)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.] 284 fstat(fd, &fd_stat); 285 pspdir[4+4*i+1] = fd_stat.st_size; 286 287 pspdir[4+4*i+2] = pos + ROM_BASE_ADDRESS; 288 pspdir[4+4*i+3] = 0; 289 ** CID 1353019: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 257 in integrate_firmwares() ________________________________________________________________________________________________________ *** CID 1353019: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 257 in integrate_firmwares() 251 break; 252 default: 253 /* Error */ 254 break; 255 } 256 >>> CID 1353019: Error handling issues (CHECKED_RETURN) >>> "read(int, void *, size_t)" returns the number of bytes read, but it is ignored. 257 read (fd, base+pos, fd_stat.st_size); 258 259 pos += fd_stat.st_size; 260 pos = ALIGN(pos, 0x100); 261 close (fd); 262 } ** CID 1353018: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 239 in integrate_firmwares() ________________________________________________________________________________________________________ *** CID 1353018: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 239 in integrate_firmwares() 233 struct stat fd_stat; 234 int i; 235 236 for (i = 0; fw_table[i].type != AMD_FW_INVALID; i ++) { 237 if (fw_table[i].filename != NULL) { 238 fd = open (fw_table[i].filename, O_RDONLY); >>> CID 1353018: Error handling issues (CHECKED_RETURN) >>> Calling "fstat(fd, &fd_stat)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.] 239 fstat(fd, &fd_stat); 240 241 switch (fw_table[i].type) { 242 case AMD_FW_IMC: 243 pos = ALIGN(pos, 0x10000); 244 romsig[1] = pos + ROM_BASE_ADDRESS; ** CID 1347358: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 586 in main() ________________________________________________________________________________________________________ *** CID 1347358: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 586 in main() 580 current = integrate_psp_firmwares(rom, current, psp2dir, amd_psp2_fw_table); 581 #endif 582 } 583 #endif 584 585 targetfd = open(output, O_RDWR | O_CREAT | O_TRUNC, 0666); >>> CID 1347358: Error handling issues (NEGATIVE_RETURNS) >>> "targetfd" is passed to a parameter that cannot be negative. 586 write(targetfd, amd_romsig, current - AMD_ROMSIG_OFFSET); 587 close(targetfd); 588 free(rom); 589 590 return 0; ** CID 1347333: Memory - illegal accesses (UNINIT) /util/amdfwtool/amdfwtool.c: 585 in main() ________________________________________________________________________________________________________ *** CID 1347333: Memory - illegal accesses (UNINIT) /util/amdfwtool/amdfwtool.c: 585 in main() 579 #else 580 current = integrate_psp_firmwares(rom, current, psp2dir, amd_psp2_fw_table); 581 #endif 582 } 583 #endif 584 >>> CID 1347333: Memory - illegal accesses (UNINIT) >>> Using uninitialized value "output" when calling "open". 585 targetfd = open(output, O_RDWR | O_CREAT | O_TRUNC, 0666); 586 write(targetfd, amd_romsig, current - AMD_ROMSIG_OFFSET); 587 close(targetfd); 588 free(rom); 589 590 return 0; ** CID 1325840: Memory - illegal accesses (OVERRUN) /util/cbfstool/cbfs_image.c: 1406 in cbfs_print_entry_info() ________________________________________________________________________________________________________ *** CID 1325840: Memory - illegal accesses (OVERRUN) /util/cbfstool/cbfs_image.c: 1406 in cbfs_print_entry_info() 1400 while ((hash = cbfs_file_get_next_hash(entry, hash)) != NULL) { 1401 unsigned int hash_type = ntohl(hash->hash_type); 1402 if (hash_type > CBFS_NUM_SUPPORTED_HASHES) { 1403 fprintf(fp, "invalid hash type %d\n", hash_type); 1404 break; 1405 } >>> CID 1325840: Memory - illegal accesses (OVERRUN) >>> Overrunning array "widths_cbfs_hash" of 4 8-byte elements at element index 4 (byte offset 32) using index "hash_type" (which evaluates to 4). 1406 size_t hash_len = widths_cbfs_hash[hash_type]; 1407 char *hash_str = bintohex(hash->hash_data, hash_len); 1408 uint8_t local_hash[hash_len]; 1409 if (vb2_digest_buffer(CBFS_SUBHEADER(entry), 1410 ntohl(entry->len), hash_type, local_hash, 1411 hash_len) != VB2_SUCCESS) { ** CID 1325836: Resource leaks (RESOURCE_LEAK) /util/cbfstool/cbfs_image.c: 1413 in cbfs_print_entry_info() ________________________________________________________________________________________________________ *** CID 1325836: Resource leaks (RESOURCE_LEAK) /util/cbfstool/cbfs_image.c: 1413 in cbfs_print_entry_info() 1407 char *hash_str = bintohex(hash->hash_data, hash_len); 1408 uint8_t local_hash[hash_len]; 1409 if (vb2_digest_buffer(CBFS_SUBHEADER(entry), 1410 ntohl(entry->len), hash_type, local_hash, 1411 hash_len) != VB2_SUCCESS) { 1412 fprintf(fp, "failed to hash '%s'\n", name); >>> CID 1325836: Resource leaks (RESOURCE_LEAK) >>> Variable "hash_str" going out of scope leaks the storage it points to. 1413 break; 1414 } 1415 int valid = memcmp(local_hash, hash->hash_data, hash_len) == 0; 1416 const char *valid_str = valid ? "valid" : "invalid"; 1417 1418 fprintf(fp, " hash %s:%s %s\n", ** CID 1323515: Error handling issues (CHECKED_RETURN) /util/broadcom/secimage/sbi.c: 112 in CreateSecureBootImage() ________________________________________________________________________________________________________ *** CID 1323515: Error handling issues (CHECKED_RETURN) /util/broadcom/secimage/sbi.c: 112 in CreateSecureBootImage() 106 } else { 107 return SBIUsage(); 108 } 109 --ac, ++av; 110 } 111 >>> CID 1323515: Error handling issues (CHECKED_RETURN) >>> Calling "stat(bl, &file_stat)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.] 112 stat(bl, &file_stat); 113 filesize = file_stat.st_size + MIN_SIZE; 114 buf = calloc(sizeof(uint8_t), filesize); 115 116 if (buf == NULL) { 117 puts("Memory allocation error"); ** CID 1323512: Null pointer dereferences (FORWARD_NULL) /util/broadcom/secimage/sbi.c: 112 in CreateSecureBootImage() ________________________________________________________________________________________________________ *** CID 1323512: Null pointer dereferences (FORWARD_NULL) /util/broadcom/secimage/sbi.c: 112 in CreateSecureBootImage() 106 } else { 107 return SBIUsage(); 108 } 109 --ac, ++av; 110 } 111 >>> CID 1323512: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "bl" to "stat", which dereferences it. [Note: The source code implementation of the function has been overridden by a builtin model.] 112 stat(bl, &file_stat); 113 filesize = file_stat.st_size + MIN_SIZE; 114 buf = calloc(sizeof(uint8_t), filesize); 115 116 if (buf == NULL) { 117 puts("Memory allocation error"); ** CID 1323511: Null pointer dereferences (FORWARD_NULL) /util/broadcom/secimage/sbi.c: 80 in CreateSecureBootImage() ________________________________________________________________________________________________________ *** CID 1323511: Null pointer dereferences (FORWARD_NULL) /util/broadcom/secimage/sbi.c: 80 in CreateSecureBootImage() 74 * Purpose : 75 * Input : none 76 * Output : none 77 *---------------------------------------------------------------------*/ 78 int CreateSecureBootImage(int ac, char **av) 79 { >>> CID 1323511: Null pointer dereferences (FORWARD_NULL) >>> Assigning: "privkey" = "NULL". 80 char *outfile, *configfile, *arg, *privkey = NULL, *bl = NULL; 81 int status = 0; 82 uint32_t sbiLen; 83 struct stat file_stat; 84 uint32_t add_header = 1; 85 outfile = *av; ** CID 1323510: Error handling issues (NEGATIVE_RETURNS) /util/broadcom/secimage/io.c: 81 in DataRead() ________________________________________________________________________________________________________ *** CID 1323510: Error handling issues (NEGATIVE_RETURNS) /util/broadcom/secimage/io.c: 81 in DataRead() 75 len = FileSizeGet(file); 76 if (len < *length) 77 *length = len; 78 else 79 /* Do not exceed the maximum length of the buffer */ 80 len = *length; >>> CID 1323510: Error handling issues (NEGATIVE_RETURNS) >>> "len" is passed to a parameter that cannot be negative. 81 if (fread((uint8_t *)buf, 1, len, file) != len) { 82 printf("Error reading data (%d bytes) from file: %s\n", 83 len, filename); 84 return -1; 85 } 86 fclose(file); ** CID 1323509: Resource leaks (RESOURCE_LEAK) /util/broadcom/secimage/io.c: 84 in DataRead() ________________________________________________________________________________________________________ *** CID 1323509: Resource leaks (RESOURCE_LEAK) /util/broadcom/secimage/io.c: 84 in DataRead() 78 else 79 /* Do not exceed the maximum length of the buffer */ 80 len = *length; 81 if (fread((uint8_t *)buf, 1, len, file) != len) { 82 printf("Error reading data (%d bytes) from file: %s\n", 83 len, filename); >>> CID 1323509: Resource leaks (RESOURCE_LEAK) >>> Variable "file" going out of scope leaks the storage it points to. 84 return -1; 85 } 86 fclose(file); 87 return 0; 88 } 89 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Denver 2017 coreboot conference
by gaumless＠gmail.com 12 Sep '16

12 Sep '16

I've invited you to fill out the following form: Denver 2017 coreboot conference To fill it out, visit: https://docs.google.com/forms/d/e/1FAIpQLSdCBqhLI3V-eg9FHg8S6QtrJWqbTCGKh42… We're trying to get a rough headcount for the Denver coreboot convention. Responding to this does not commit you to anything. Google Forms: Create and analyze surveys.

1 0

Re: [coreboot] Experiments with disabling the ME on Sandybridge x230
by Peter Stuge 12 Sep '16

12 Sep '16

ron minnich wrote: > I was thinking that the x230 was so old it would just keep running, > is that possible? I know that on newer platforms you only get the > 30 minutes. AFAIK the very last platform where the ME does not shut down the platform is Core 2 Duo + GM45 chipset. From Nehalem, ie. with Core microarchitecture, it's 30 minutes. //Peter

1 0

Re: [coreboot] Experiments with disabling the ME on Sandybridge x230
by Peter Stuge 12 Sep '16

12 Sep '16

ron minnich wrote: > That's pretty interesting. I had no idea that would work. > > I wonder if erasing it all erases that little boot of the ME you need to > get the hardware going, whereas the 4KB erase lets the little bootstrap > run but disables the ME otherwise. If so, that's great news. The ME code to start the platform is in (on-chip) ROM and a failed signature check of the (compressed with AFAIK still unknown codebook) ME code in flash just means that the ME considers the system broken and allows it to run for a little while so that a human can repair it. It's described pretty well in the Platform Embedded Security Revealed book, along with the fact that the ME will sync it's internal clock with NTP servers across the internet once every 30 days, to make CRL checks for the remote management PKI work. Maybe this particular thing doesn't happen with the smaller ME firmware. Dunno. //Peter

2 1

how to start all ap under smm
by 汤科峰 12 Sep '16

12 Sep '16

Hi all, I am now working on a project which need DTS(Digital Thermal Sensor) support. But I find that I can't to run a handler on every ap and bsp in smm_handler_start in smm_module_handler.c . Is there a simple way to make it easier to run a handler on all aps and bsp? Thanks, Tank

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2016