Better here, sorry.
https://github.com/osresearch/heads/issues/134
Le ven. 23 févr. 2018 00:26, Thierry Laurion <thierry.laurion(a)gmail.com> a
écrit :
> Actually if others of you want to contribute, there is this heads kgpe-d16
> port that permits to flash directly from the heads coreboot payload with
> Timothy's patches on the flashrom tools. You may want to take a look here :
> https://github.com/flammit/heads/pull/9#issuecomment-362022411
>
> Le jeu. 22 févr. 2018 16:37, Timothy Pearson <
> tpearson(a)raptorengineering.com> a écrit :
>
>> Actually, for OpenBMC work, hotplugging is often the only way to go.
>> Just be very careful to align the pins correctly the first time; you
>> don't have a second chance if you misalign the pins and fry the module...
>>
>> On 02/22/2018 03:22 PM, Taiidan(a)gmx.com wrote:
>> > On 02/17/2018 09:46 AM, Elisenda Cuadros wrote:
>> >
>> >> Hi,
>> >>
>> >> Now I trying to use your OpenBMC port.
>> >>
>> >> I followed the instructions and everything was fine (compiling,
>> >> reading and flashing). I waited several minutes after flashing, but
>> >> the module didn 't blinked like in the vendor rom, nor did it receive
>> >> an ip.
>> >>
>> >> I halted the system because I thought maybe it needs a cold start.
>> >>
>> >> After this, the system doesn't boot with the module plugged in. The
>> >> fans begin to spin for approximately 1/4 second, but nothing else.
>> >>
>> >> My two fans (1 cpu & 1 chassis) have 3 pins and are low speed
>> (~1000rpm)
>> >>
>> >> In the case I have to reflash the module, is it possible to hotplug it?
>> > Hotplugging is dangerous and not supported, don't do it.
>> >> Thank you very much for your support.
>> > You can use a test clip to externally flash it via a flashing device
>> > (not sure which can do 16 pins though, I would inquire on the flashrom
>> > mailinglist)
>> >
>> > Are you using the latest coreboot? AFAIK coreboot was patched to support
>> > OpenBMC, so you need a new version with the patches.
>>
>>
>> --
>> Timothy Pearson
>> Raptor Engineering
>> +1 (415) 727-8645 (direct line)
>> +1 (512) 690-0200 (switchboard)
>> https://www.raptorengineering.com
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
On 02/20/2018 01:29 AM, 戴，曉政 via coreboot wrote:
> Dear Taiidan,
>
> I have get KGPE-D16 motherboard from auction website but I find that AMD 6328 CPU is too expensive ($499 USD). As well as 6386SE CPU is more expensive than 6328 CPU so please give me a favor. Please list some cheaper AMD CPUs name that can be built successfully when I use KGPE-D16 motherboard to install coreboot.
Right now on ebay I also see a 6328 for $130 and a 6386SE for $225/best
offer (the last and best owner controlled x86-64 CPU, get one while you
can IMO).
https://www.ebay.com/itm/AMD-Opteron-OS6386YETGGHK-16-Core-2-8GHz-16MB-6-4G…
This one is in good condition (note the straight as an arrow capacitors
on the bottom with none missing)
FYI don't buy a CPU that has missing bottom capacitors or scratches on
the pads, always ask a seller for a photo of the bottom if you buy a G34
CPU like the 6386SE.
> I know my English is very poor,
Naah it is fine :]
Hello,
I have coreboot'ed my Lenovo X230 a while ago and run it with SeaBIOS as I needed a DualBoot Setup (Qubes OS + Win 10).
After I had issues with standby/resume I decided to delete windows and run a Qubes OS only setup.
in order to troublesshoot the problems with standby/resume, I decided to reflash the stock rom and reinstalled Qubes from scratch.
Unfortunately it seems that the problem with standby is still there:
If I close the lid, the laptop shuts off. It seems that it doesn't run a real clean shutdown as the shutdown is way to fast.
Question:
Could it be that something "broke" internally while flashing/reflashing Coreboot?
Where can I start troubleshooting?
I have already reset my BIOS to factory defaults - problem is still there:
Close the laptop lid -> laptop goes off within.3sec.
[799]
--
Qubes 4rc3 + Coreboot > Lenovo X230
Qubes 4rc4 > Lenovo W540
Hi Taiidan,
> I purchased a used g34 opteron off of fleabay (sold as working with no
> mention of this) and I noticed that it is missing some of the bits on
> the bottom and that most of them are crooked, I haven't tried it in my
> system yet and I am wondering should return it? or if there isn't any
> much risk of it damaging my (expensive kgpe-d16) motherboard and I
> should see if it works?
> I got it for half the usual price....guess I should have asked for photos.
>
> I noticed many CPU's sold on ebay have this issue (in those cases they
> mentioned it) but I can't understand how it happens, for instance I
> noticed a 6386 for sale where they mentioned that it was missing a few
> and because of that it doesn't work in a dual socket configuration.
I have a few Opterons which have this issue and it seems to pretty common. I assume that some "expert" put the CPU on a table before mounting it, and they move it one the table - can't imaging how people manage to chop off the chips otherwise. While some of these damaged CPUs seem to work just fine, I had several which do not recognize more than 1-2 pcs of memory and, thus, would not recommend buying one of these.
Cheers, Daniel
Hi,
Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan.
24 new defect(s) introduced to coreboot found with Coverity Scan.
14 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 24 defect(s)
** CID 1383919: Resource leaks (RESOURCE_LEAK)
/util/cbfstool/partitioned_file.c: 201 in partitioned_file_reopen()
________________________________________________________________________________________________________
*** CID 1383919: Resource leaks (RESOURCE_LEAK)
/util/cbfstool/partitioned_file.c: 201 in partitioned_file_reopen()
195 }
196
197 const struct fmap_area *fmap_fmap_entry =
198 fmap_find_area(file->fmap, SECTION_NAME_FMAP);
199
200 if (!fmap_fmap_entry)
>>> CID 1383919: Resource leaks (RESOURCE_LEAK)
>>> Variable "file" going out of scope leaks the storage it points to.
201 return NULL;
202
203 if ((long)fmap_fmap_entry->offset != fmap_region_offset) {
204 ERROR("FMAP's '%s' section doesn't point back to FMAP start (did something corrupt this file?)\n",
205 SECTION_NAME_FMAP);
206 partitioned_file_close(file);
** CID 1361275: (TAINTED_SCALAR)
/util/cbfstool/ifwitool.c: 839 in parse_subpart_dir()
________________________________________________________________________________________________________
*** CID 1361275: (TAINTED_SCALAR)
/util/cbfstool/ifwitool.c: 832 in parse_subpart_dir()
826 memcpy(hdr.name, data + offset, sizeof(hdr.name));
827 offset += sizeof(hdr.name);
828
829 validate_subpart_dir_without_checksum((struct subpart_dir *)&hdr, name);
830
831 assert(size > subpart_dir_size(&hdr));
>>> CID 1361275: (TAINTED_SCALAR)
>>> Passing tainted variable "subpart_dir_size(&hdr)" to a tainted sink.
832 alloc_buffer(subpart_dir_buf, subpart_dir_size(&hdr), "Subpart Dir");
833 memcpy(buffer_get(subpart_dir_buf), &hdr, SUBPART_DIR_HEADER_SIZE);
834
835 /* Read Subpart Dir entries. */
836 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf);
837 struct subpart_dir_entry *e = &subpart_dir->e[0];
/util/cbfstool/ifwitool.c: 839 in parse_subpart_dir()
833 memcpy(buffer_get(subpart_dir_buf), &hdr, SUBPART_DIR_HEADER_SIZE);
834
835 /* Read Subpart Dir entries. */
836 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf);
837 struct subpart_dir_entry *e = &subpart_dir->e[0];
838 uint32_t i;
>>> CID 1361275: (TAINTED_SCALAR)
>>> Using tainted variable "hdr.num_entries" as a loop boundary.
839 for (i = 0; i < hdr.num_entries; i++) {
840 memcpy(e[i].name, data + offset, sizeof(e[i].name));
841 offset += sizeof(e[i].name);
842 offset = read_member(data, offset, sizeof(e[i].offset),
843 &e[i].offset);
844 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: 718 in alloc_bpdt_buffer()
712 {
713 struct bpdt_header bpdt_header;
714 assert((offset + BPDT_HEADER_SIZE) < size);
715 bpdt_read_header((uint8_t *)data + offset, &bpdt_header, name);
716
717 /* 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.
718 alloc_buffer(b, get_bpdt_size(&bpdt_header), name);
719
720 struct bpdt *bpdt = buffer_get(b);
721 memcpy(&bpdt->h, &bpdt_header, BPDT_HEADER_SIZE);
722
723 /*
** CID 1361253: Memory - illegal accesses (BUFFER_SIZE_WARNING)
/util/cbfstool/ifwitool.c: 1301 in init_subpart_dir_entry()
________________________________________________________________________________________________________
*** CID 1361253: Memory - illegal accesses (BUFFER_SIZE_WARNING)
/util/cbfstool/ifwitool.c: 1301 in init_subpart_dir_entry()
1295 static size_t init_subpart_dir_entry(struct subpart_dir_entry *e,
1296 struct buffer *b, size_t offset)
1297 {
1298 memset(e, 0, sizeof(*e));
1299
1300 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.
1301 strncpy((char *)e->name, (char *)b->name, sizeof(e->name));
1302 e->offset = offset;
1303 e->length = buffer_size(b);
1304
1305 return (offset + buffer_size(b));
1306 }
** CID 1353022: Error handling issues (CHECKED_RETURN)
/util/nvidia/cbootimage/src/cbootimage.c: 297 in main()
________________________________________________________________________________________________________
*** CID 1353022: Error handling issues (CHECKED_RETURN)
/util/nvidia/cbootimage/src/cbootimage.c: 297 in main()
291 begin_update(&context);
292 /* Signing the bct. */
293 e = sign_bct(&context, context.bct);
294 if (e != 0)
295 printf("Signing BCT failed, error: %d.\n", e);
296
>>> CID 1353022: Error handling issues (CHECKED_RETURN)
>>> Calling "fwrite" without checking return value (as is done elsewhere 39 out of 48 times).
297 fwrite(context.bct, 1, context.bct_size,
298 context.raw_file);
299 printf("New BCT file %s has been successfully generated!\n",
300 context.output_image_filename);
301 goto fail;
302 }
** CID 1353020: Error handling issues (CHECKED_RETURN)
/util/amdfwtool/amdfwtool.c: 372 in integrate_psp_firmwares()
________________________________________________________________________________________________________
*** CID 1353020: Error handling issues (CHECKED_RETURN)
/util/amdfwtool/amdfwtool.c: 372 in integrate_psp_firmwares()
366 fd = open(fw_table[i].filename, O_RDONLY);
367 if (fd < 0) {
368 printf("Error: %s\n", strerror(errno));
369 free(base);
370 exit(1);
371 }
>>> 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.]
372 fstat(fd, &fd_stat);
373 pspdir[4+4*i+1] = (uint32_t)fd_stat.st_size;
374
375 pspdir[4+4*i+2] = pos + rom_base_address;
376 pspdir[4+4*i+3] = 0;
377
** CID 1353018: Error handling issues (CHECKED_RETURN)
/util/amdfwtool/amdfwtool.c: 301 in integrate_firmwares()
________________________________________________________________________________________________________
*** CID 1353018: Error handling issues (CHECKED_RETURN)
/util/amdfwtool/amdfwtool.c: 301 in integrate_firmwares()
295 fd = open(fw_table[i].filename, O_RDONLY);
296 if (fd < 0) {
297 printf("Error: %s\n", strerror(errno));
298 free(base);
299 exit(1);
300 }
>>> 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.]
301 fstat(fd, &fd_stat);
302
303 switch (fw_table[i].type) {
304 case AMD_FW_IMC:
305 pos = ALIGN(pos, 0x10000U);
306 romsig[1] = pos + rom_base_address;
** CID 1347335: (UNINIT)
/util/cbfstool/elfheaders.c: 1000 in write_phdrs()
/util/cbfstool/elfheaders.c: 1002 in write_phdrs()
/util/cbfstool/elfheaders.c: 1003 in write_phdrs()
/util/cbfstool/elfheaders.c: 1004 in write_phdrs()
________________________________________________________________________________________________________
*** CID 1347335: (UNINIT)
/util/cbfstool/elfheaders.c: 1000 in write_phdrs()
994 } else {
995 /* Accumulate file size and memsize. The assumption
996 * is that each section is either NOBITS or full
997 * (sh_size == file size). This is standard in that
998 * an ELF section doesn't have a file size component. */
999 if (sec->shdr.sh_flags & SHF_EXECINSTR)
>>> CID 1347335: (UNINIT)
>>> Using uninitialized value "phdr.p_flags".
1000 phdr.p_flags |= PF_X | PF_R;
1001 if (sec->shdr.sh_flags & SHF_WRITE)
1002 phdr.p_flags |= PF_W;
1003 phdr.p_filesz += buffer_size(&sec->content);
1004 phdr.p_memsz += sec->shdr.sh_size;
1005 }
/util/cbfstool/elfheaders.c: 1002 in write_phdrs()
996 * is that each section is either NOBITS or full
997 * (sh_size == file size). This is standard in that
998 * an ELF section doesn't have a file size component. */
999 if (sec->shdr.sh_flags & SHF_EXECINSTR)
1000 phdr.p_flags |= PF_X | PF_R;
1001 if (sec->shdr.sh_flags & SHF_WRITE)
>>> CID 1347335: (UNINIT)
>>> Using uninitialized value "phdr.p_flags".
1002 phdr.p_flags |= PF_W;
1003 phdr.p_filesz += buffer_size(&sec->content);
1004 phdr.p_memsz += sec->shdr.sh_size;
1005 }
1006 }
1007
/util/cbfstool/elfheaders.c: 1003 in write_phdrs()
997 * (sh_size == file size). This is standard in that
998 * an ELF section doesn't have a file size component. */
999 if (sec->shdr.sh_flags & SHF_EXECINSTR)
1000 phdr.p_flags |= PF_X | PF_R;
1001 if (sec->shdr.sh_flags & SHF_WRITE)
1002 phdr.p_flags |= PF_W;
>>> CID 1347335: (UNINIT)
>>> Using uninitialized value "phdr.p_filesz".
1003 phdr.p_filesz += buffer_size(&sec->content);
1004 phdr.p_memsz += sec->shdr.sh_size;
1005 }
1006 }
1007
1008 /* Write out the last phdr. */
/util/cbfstool/elfheaders.c: 1004 in write_phdrs()
998 * an ELF section doesn't have a file size component. */
999 if (sec->shdr.sh_flags & SHF_EXECINSTR)
1000 phdr.p_flags |= PF_X | PF_R;
1001 if (sec->shdr.sh_flags & SHF_WRITE)
1002 phdr.p_flags |= PF_W;
1003 phdr.p_filesz += buffer_size(&sec->content);
>>> CID 1347335: (UNINIT)
>>> Using uninitialized value "phdr.p_memsz".
1004 phdr.p_memsz += sec->shdr.sh_size;
1005 }
1006 }
1007
1008 /* Write out the last phdr. */
1009 if (num_needs_write != num_written) {
** CID 1302457: Control flow issues (MISSING_RESTORE)
/util/cbfstool/flashmap/fmap.c: 486 in fmap_append_area_test()
________________________________________________________________________________________________________
*** CID 1302457: Control flow issues (MISSING_RESTORE)
/util/cbfstool/flashmap/fmap.c: 486 in fmap_append_area_test()
480 printf("FAILURE: failed to increment number of areas\n");
481 goto fmap_append_area_test_exit;
482 }
483
484 status = pass;
485 fmap_append_area_test_exit:
>>> CID 1302457: Control flow issues (MISSING_RESTORE)
>>> Value of non-local "(*fmap)->nareas" that was saved in "nareas_orig" is not restored as it was along other paths.
486 return status;
487 }
488
489 static int fmap_find_area_test(struct fmap *fmap)
490 {
491 status = fail;
** CID 1302456: Error handling issues (NEGATIVE_RETURNS)
/util/cbfstool/flashmap/fmap.c: 601 in fmap_find_test()
________________________________________________________________________________________________________
*** CID 1302456: Error handling issues (NEGATIVE_RETURNS)
/util/cbfstool/flashmap/fmap.c: 601 in fmap_find_test()
595 printf("FAILURE: bsearch returned false positive\n");
596 goto fmap_find_test_exit;
597 }
598
599 /* simple test case: fmap at (total_size / 2) + 1 */
600 offset = (total_size / 2) + 1;
>>> CID 1302456: Error handling issues (NEGATIVE_RETURNS)
>>> "fmap_size(fmap)" is passed to a parameter that cannot be negative. [Note: The source code implementation of the function has been overridden by a builtin model.]
601 memcpy(&buf[offset], fmap, fmap_size(fmap));
602
603 if ((unsigned)fmap_find(buf, total_size - 1) != offset) {
604 printf("FAILURE: lsearch failed to find fmap\n");
605 goto fmap_find_test_exit;
606 }
** CID 1302453: Resource leaks (RESOURCE_LEAK)
/util/cbfstool/flashmap/fmap.c: 563 in fmap_flags_to_string_test()
________________________________________________________________________________________________________
*** CID 1302453: Resource leaks (RESOURCE_LEAK)
/util/cbfstool/flashmap/fmap.c: 563 in fmap_flags_to_string_test()
557 }
558 free(my_str);
559 free(str);
560
561 status = pass;
562 fmap_flags_to_string_test_exit:
>>> CID 1302453: Resource leaks (RESOURCE_LEAK)
>>> Variable "my_str" going out of scope leaks the storage it points to.
563 return status;
564
565 }
566
567 static int fmap_find_test(struct fmap *fmap)
568 {
** CID 1302452: (RESOURCE_LEAK)
/util/cbfstool/flashmap/fmap.c: 563 in fmap_flags_to_string_test()
/util/cbfstool/flashmap/fmap.c: 563 in fmap_flags_to_string_test()
________________________________________________________________________________________________________
*** CID 1302452: (RESOURCE_LEAK)
/util/cbfstool/flashmap/fmap.c: 563 in fmap_flags_to_string_test()
557 }
558 free(my_str);
559 free(str);
560
561 status = pass;
562 fmap_flags_to_string_test_exit:
>>> CID 1302452: (RESOURCE_LEAK)
>>> Variable "str" going out of scope leaks the storage it points to.
563 return status;
564
565 }
566
567 static int fmap_find_test(struct fmap *fmap)
568 {
/util/cbfstool/flashmap/fmap.c: 563 in fmap_flags_to_string_test()
557 }
558 free(my_str);
559 free(str);
560
561 status = pass;
562 fmap_flags_to_string_test_exit:
>>> CID 1302452: (RESOURCE_LEAK)
>>> Variable "str" going out of scope leaks the storage it points to.
563 return status;
564
565 }
566
567 static int fmap_find_test(struct fmap *fmap)
568 {
** CID 1302451: Resource leaks (RESOURCE_LEAK)
/util/cbfstool/flashmap/fmap.c: 240 in fmap_print()
________________________________________________________________________________________________________
*** CID 1302451: Resource leaks (RESOURCE_LEAK)
/util/cbfstool/flashmap/fmap.c: 240 in fmap_print()
234 kv_pair_fmt(pair, "area_flags_raw", "0x%02x",
235 fmap->areas[i].flags);
236
237 /* Print descriptive strings for flags rather than the field */
238 flags = fmap->areas[i].flags;
239 if ((str = fmap_flags_to_string(flags)) == NULL)
>>> CID 1302451: Resource leaks (RESOURCE_LEAK)
>>> Variable "pair" going out of scope leaks the storage it points to.
240 return -1;
241 kv_pair_fmt(pair, "area_flags", "%s", str);
242 free(str);
243
244 kv_pair_print(pair);
245 kv_pair_free(pair);
** CID 1241790: Insecure data handling (TAINTED_SCALAR)
/util/cbfstool/lzma/C/LzFind.c: 653 in Bt2_MatchFinder_Skip()
________________________________________________________________________________________________________
*** CID 1241790: Insecure data handling (TAINTED_SCALAR)
/util/cbfstool/lzma/C/LzFind.c: 653 in Bt2_MatchFinder_Skip()
647 static void Bt2_MatchFinder_Skip(struct CMatchFinder *p, uint32_t num)
648 {
649 do
650 {
651 SKIP_HEADER(2)
652 HASH2_CALC;
>>> CID 1241790: Insecure data handling (TAINTED_SCALAR)
>>> Using tainted variable "hashValue" as an index to pointer "p->hash".
653 curMatch = p->hash[hashValue];
654 p->hash[hashValue] = p->pos;
655 SKIP_FOOTER
656 }
657 while (--num != 0);
658 }
** CID 1241788: Insecure data handling (TAINTED_SCALAR)
/util/cbfstool/lzma/C/LzFind.c: 489 in Bt2_MatchFinder_GetMatches()
________________________________________________________________________________________________________
*** CID 1241788: Insecure data handling (TAINTED_SCALAR)
/util/cbfstool/lzma/C/LzFind.c: 489 in Bt2_MatchFinder_GetMatches()
483
484 static uint32_t Bt2_MatchFinder_GetMatches(struct CMatchFinder *p, uint32_t *distances)
485 {
486 uint32_t offset;
487 GET_MATCHES_HEADER(2)
488 HASH2_CALC;
>>> CID 1241788: Insecure data handling (TAINTED_SCALAR)
>>> Using tainted variable "hashValue" as an index to pointer "p->hash".
489 curMatch = p->hash[hashValue];
490 p->hash[hashValue] = p->pos;
491 offset = 0;
492 GET_MATCHES_FOOTER(offset, 1)
493 }
494
** CID 1229710: Integer handling issues (SIGN_EXTENSION)
/util/cbfstool/elfheaders.c: 265 in phdr_read()
________________________________________________________________________________________________________
*** CID 1229710: Integer handling issues (SIGN_EXTENSION)
/util/cbfstool/elfheaders.c: 265 in phdr_read()
259 ehdr = &pelf->ehdr;
260 /* cons up an input buffer for the headers.
261 * Note that the program headers can be anywhere,
262 * per the ELF spec, You'd be surprised how many ELF
263 * readers miss this little detail.
264 */
>>> CID 1229710: Integer handling issues (SIGN_EXTENSION)
>>> Suspicious implicit sign extension: "ehdr->e_phentsize" with type "Elf64_Half" (16 bits, unsigned) is promoted in "ehdr->e_phentsize * ehdr->e_phnum" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "ehdr->e_phentsize * ehdr->e_phnum" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
265 buffer_splice(&b, in, ehdr->e_phoff, ehdr->e_phentsize * ehdr->e_phnum);
266 if (check_size(in, ehdr->e_phoff, buffer_size(&b), "program headers"))
267 return -1;
268
269 /* gather up all the phdrs.
270 * We do them all at once because there is more
** CID 1229709: Integer handling issues (SIGN_EXTENSION)
/util/cbfstool/elfheaders.c: 265 in phdr_read()
________________________________________________________________________________________________________
*** CID 1229709: Integer handling issues (SIGN_EXTENSION)
/util/cbfstool/elfheaders.c: 265 in phdr_read()
259 ehdr = &pelf->ehdr;
260 /* cons up an input buffer for the headers.
261 * Note that the program headers can be anywhere,
262 * per the ELF spec, You'd be surprised how many ELF
263 * readers miss this little detail.
264 */
>>> CID 1229709: Integer handling issues (SIGN_EXTENSION)
>>> Suspicious implicit sign extension: "ehdr->e_phnum" with type "Elf64_Half" (16 bits, unsigned) is promoted in "ehdr->e_phentsize * ehdr->e_phnum" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "ehdr->e_phentsize * ehdr->e_phnum" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
265 buffer_splice(&b, in, ehdr->e_phoff, ehdr->e_phentsize * ehdr->e_phnum);
266 if (check_size(in, ehdr->e_phoff, buffer_size(&b), "program headers"))
267 return -1;
268
269 /* gather up all the phdrs.
270 * We do them all at once because there is more
** CID 1229708: Integer handling issues (SIGN_EXTENSION)
/util/cbfstool/elfheaders.c: 307 in shdr_read()
________________________________________________________________________________________________________
*** CID 1229708: Integer handling issues (SIGN_EXTENSION)
/util/cbfstool/elfheaders.c: 307 in shdr_read()
301
302 /* cons up an input buffer for the section headers.
303 * Note that the section headers can be anywhere,
304 * per the ELF spec, You'd be surprised how many ELF
305 * readers miss this little detail.
306 */
>>> CID 1229708: Integer handling issues (SIGN_EXTENSION)
>>> Suspicious implicit sign extension: "ehdr->e_shentsize" with type "Elf64_Half" (16 bits, unsigned) is promoted in "ehdr->e_shentsize * ehdr->e_shnum" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "ehdr->e_shentsize * ehdr->e_shnum" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
307 buffer_splice(&b, in, ehdr->e_shoff, ehdr->e_shentsize * ehdr->e_shnum);
308 if (check_size(in, ehdr->e_shoff, buffer_size(&b), "section headers"))
309 return -1;
310
311 /* gather up all the shdrs. */
312 shdr = calloc(ehdr->e_shnum, sizeof(*shdr));
** CID 1229707: Integer handling issues (SIGN_EXTENSION)
/util/cbfstool/elfheaders.c: 307 in shdr_read()
________________________________________________________________________________________________________
*** CID 1229707: Integer handling issues (SIGN_EXTENSION)
/util/cbfstool/elfheaders.c: 307 in shdr_read()
301
302 /* cons up an input buffer for the section headers.
303 * Note that the section headers can be anywhere,
304 * per the ELF spec, You'd be surprised how many ELF
305 * readers miss this little detail.
306 */
>>> CID 1229707: Integer handling issues (SIGN_EXTENSION)
>>> Suspicious implicit sign extension: "ehdr->e_shnum" with type "Elf64_Half" (16 bits, unsigned) is promoted in "ehdr->e_shentsize * ehdr->e_shnum" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "ehdr->e_shentsize * ehdr->e_shnum" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
307 buffer_splice(&b, in, ehdr->e_shoff, ehdr->e_shentsize * ehdr->e_shnum);
308 if (check_size(in, ehdr->e_shoff, buffer_size(&b), "section headers"))
309 return -1;
310
311 /* gather up all the shdrs. */
312 shdr = calloc(ehdr->e_shnum, sizeof(*shdr));
** CID 1229706: (SIGN_EXTENSION)
/util/cbfstool/elfheaders.c: 1181 in elf_writer_serialize()
/util/cbfstool/elfheaders.c: 1204 in elf_writer_serialize()
________________________________________________________________________________________________________
*** CID 1229706: (SIGN_EXTENSION)
/util/cbfstool/elfheaders.c: 1181 in elf_writer_serialize()
1175 }
1176 }
1177 ew->ehdr.e_shnum = ew->num_secs;
1178 metadata_size = 0;
1179 metadata_size += ew->ehdr.e_ehsize;
1180 metadata_size += ew->ehdr.e_shnum * ew->ehdr.e_shentsize;
>>> CID 1229706: (SIGN_EXTENSION)
>>> Suspicious implicit sign extension: "ew->ehdr.e_phentsize" with type "Elf64_Half" (16 bits, unsigned) is promoted in "ew->ehdr.e_phnum * ew->ehdr.e_phentsize" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "ew->ehdr.e_phnum * ew->ehdr.e_phentsize" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
1181 metadata_size += ew->ehdr.e_phnum * ew->ehdr.e_phentsize;
1182 shstroffset = metadata_size;
1183 /* Align up section header string size and metadata size to 4KiB */
1184 metadata_size = ALIGN(metadata_size + shstrlen, 4096);
1185
1186 if (buffer_create(out, metadata_size + program_size, "elfout")) {
/util/cbfstool/elfheaders.c: 1204 in elf_writer_serialize()
1198 ew->ehdr.e_shoff = ew->ehdr.e_ehsize;
1199 ew->ehdr.e_phoff = ew->ehdr.e_shoff +
1200 ew->ehdr.e_shnum * ew->ehdr.e_shentsize;
1201
1202 buffer_splice(&metadata, out, 0, metadata_size);
1203 buffer_splice(&phdrs, out, ew->ehdr.e_phoff,
>>> CID 1229706: (SIGN_EXTENSION)
>>> Suspicious implicit sign extension: "ew->ehdr.e_phentsize" with type "Elf64_Half" (16 bits, unsigned) is promoted in "ew->ehdr.e_phnum * ew->ehdr.e_phentsize" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "ew->ehdr.e_phnum * ew->ehdr.e_phentsize" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
1204 ew->ehdr.e_phnum * ew->ehdr.e_phentsize);
1205 buffer_splice(&data, out, metadata_size, program_size);
1206 /* Set up the section header string table contents. */
1207 strtab = &ew->shstrtab_sec->content;
1208 buffer_splice(strtab, out, shstroffset, shstrlen);
1209 ew->shstrtab_sec->shdr.sh_size = shstrlen;
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…
Dear Taiidan,
I have get KGPE-D16 motherboard from auction website but I find that AMD 6328 CPU is too expensive ($499 USD). As well as 6386SE CPU is more expensive than 6328 CPU so please give me a favor. Please list some cheaper AMD CPUs name that can be built successfully when I use KGPE-D16 motherboard to install coreboot. I know my English is very poor, You can ask me more detail if you can not understand this mail fully.
> I will purchase USB CH341A along of purchase KGP-D16, thank for your suggestion
>Feel free to ask any questions you have :D
>I suggest that you purchase a 6386SE (16 cores, good for compiling) or
>6328 (8 cores, better for games) CPU
>
>6328 average $80-120 USD
>6386SE average $150-250 USD
---
Avast 防毒軟體已檢查此封電子郵件的病毒。
https://www.avast.com/antivirus
AFAIK it's not only fam15 that is vulnerable. If you're going to ask, could you ask about updates for other CPU's than Ryzen in general? I also have fam14 and fam16 boards.
On 18-02-19 12:00:01, coreboot-request(a)coreboot.org wrote:
>Send coreboot mailing list submissions to
> coreboot(a)coreboot.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.coreboot.org/mailman/listinfo/coreboot
>or, via email, send a message with subject or body 'help' to
> coreboot-request(a)coreboot.org
>
>You can reach the person managing the list at
> coreboot-owner(a)coreboot.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of coreboot digest..."
>
>
>Today's Topics:
>
> 1. Re: When does AMD release the fam15 spectre microcode
> updates? (Mike Banon)
> 2. Re: When does AMD release the fam15 spectre microcode
> updates? (Rudolf Marek)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Sun, 18 Feb 2018 14:48:05 +0300
>From: Mike Banon <mikebdp2(a)gmail.com>
>To: "Taiidan(a)gmx.com" <Taiidan(a)gmx.com>, coreboot(a)coreboot.org
>Subject: Re: [coreboot] When does AMD release the fam15 spectre
> microcode updates?
>Message-ID:
> <CAK7947kcPwzWt0mpc6UttVK-Z8SUy-cL-0E0X5Gz8RdJ41cNgg(a)mail.gmail.com>
>Content-Type: text/plain; charset="UTF-8"
>
>Maybe its' a good idea to write to AMD support regarding this question
>- please share a reply if you would get an answer. I'm curious about
>other fam15 CPUs as well, e.g. A10-5750M microcode update would be
>nice, maybe a request could be more general, e.g. : what is the
>estimated release date for the microcode updates for fam15 AMD CPUs
>(so a request is not about "opterons only")
>
>On Sun, Feb 18, 2018 at 2:47 PM, Mike Banon <mikebdp2(a)gmail.com> wrote:
>> Maybe its' a good idea to write to AMD support regarding this question
>> - please share a reply if you would get an answer. I'm curious about
>> other fam15 CPUs as well, e.g. A10-5750M microcode update would be
>> nice, maybe a request could be more general, e.g. : what is the
>> estimated release date for the microcode updates for fam15 AMD CPUs
>> (so a request is not about "opterons only")
>>
>> On Sun, Feb 18, 2018 at 4:30 AM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
>>> They said they would be releasing opteron microcode updates in a few weeks
>>> but it has been over a month and I am wondering when this is going to happen
>>> or if it already has and I should re-compile coreboot?
>>>
>>> https://www.amd.com/en/corporate/speculative-execution
>>> "We expect to make updates available for our previous generation products
>>> over the coming weeks."
>>>
>>> Thanks!
>>>
>>>
>>> --
>>> coreboot mailing list: coreboot(a)coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
>
>------------------------------
>
>Message: 2
>Date: Sun, 18 Feb 2018 13:03:07 +0100
>From: Rudolf Marek <r.marek(a)assembler.cz>
>To: Mike Banon <mikebdp2(a)gmail.com>, "Taiidan(a)gmx.com"
> <Taiidan(a)gmx.com>, coreboot(a)coreboot.org
>Subject: Re: [coreboot] When does AMD release the fam15 spectre
> microcode updates?
>Message-ID: <e4ebdd27-1446-43eb-e902-aa1ddee54d12(a)assembler.cz>
>Content-Type: text/plain; charset=iso-8859-2
>
>Hi,
>
>What do you want to protect? If you want to protect the kernel, retpolines are OK on AMD.
>And you don't need any microcode update. Your CPU needs to have SMEP, otherwise
>you would need to clear RSB on CPL change (the paper on mentined page says that you need to do that
>always, but at least on Ryzen, the attack using RSB is not working (we tried that out, maybe it works
>only on some circumstances).
>
>If you want to protect userspace, the RSB will be clear by IBPB (which you would need if you don't have userspace compiled
>with retpolines). I don't know if intel clears RSB on IBPB... probably not
>
>To sum it up on AMD:
>
>kernel:
>retpolines, RSB clear on CPL change on CPU without SMEP (see above)
>
>userspace:
>retpolines, RSB clear on context switch necessary or IBPB (needs microcode update).
>
>Plus make sure you enable "LFENCE is dispatch serializing" - perhaps coreboot can do that :) it is simple
>MSR write on fam 10h 12h+ the fam 11h and 0fh dont have this MSR but LFENCE is dispatch serilizing.
>
>Besides that, you don't need any microcode update.
>
>Plus of course there is a spectre variant 1, which is more difficult to mitigate, basically you need to check all the software
>and look for any pattern like array_x[array_z[untrusted_index] * any transformation].
>
>The first access would leak just address (ASLR defated), second will leak data.
>The variant 1 works on user/user attack and as well as user/kernel.
>
>As far I know there are no automated tools to check for this.
>
>
>Thanks
>Rudolf
>
>
>
>
>
>
>
>
>
>Dne 18.2.2018 v 12:48 Mike Banon napsal(a):
>> Maybe its' a good idea to write to AMD support regarding this question
>> - please share a reply if you would get an answer. I'm curious about
>> other fam15 CPUs as well, e.g. A10-5750M microcode update would be
>> nice, maybe a request could be more general, e.g. : what is the
>> estimated release date for the microcode updates for fam15 AMD CPUs
>> (so a request is not about "opterons only")
>>
>> On Sun, Feb 18, 2018 at 2:47 PM, Mike Banon <mikebdp2(a)gmail.com> wrote:
>>> Maybe its' a good idea to write to AMD support regarding this question
>>> - please share a reply if you would get an answer. I'm curious about
>>> other fam15 CPUs as well, e.g. A10-5750M microcode update would be
>>> nice, maybe a request could be more general, e.g. : what is the
>>> estimated release date for the microcode updates for fam15 AMD CPUs
>>> (so a request is not about "opterons only")
>>>
>>> On Sun, Feb 18, 2018 at 4:30 AM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
>>>> They said they would be releasing opteron microcode updates in a few weeks
>>>> but it has been over a month and I am wondering when this is going to happen
>>>> or if it already has and I should re-compile coreboot?
>>>>
>>>> https://www.amd.com/en/corporate/speculative-execution
>>>> "We expect to make updates available for our previous generation products
>>>> over the coming weeks."
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> --
>>>> coreboot mailing list: coreboot(a)coreboot.org
>>>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>coreboot mailing list
>coreboot(a)coreboot.org
>https://mail.coreboot.org/mailman/listinfo/coreboot
>
>------------------------------
>
>End of coreboot Digest, Vol 156, Issue 21
>*****************************************
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>
Maybe its' a good idea to write to AMD support regarding this question
- please share a reply if you would get an answer. I'm curious about
other fam15 CPUs as well, e.g. A10-5750M microcode update would be
nice, maybe a request could be more general, e.g. : what is the
estimated release date for the microcode updates for fam15 AMD CPUs
(so a request is not about "opterons only")
On Sun, Feb 18, 2018 at 2:47 PM, Mike Banon <mikebdp2(a)gmail.com> wrote:
> Maybe its' a good idea to write to AMD support regarding this question
> - please share a reply if you would get an answer. I'm curious about
> other fam15 CPUs as well, e.g. A10-5750M microcode update would be
> nice, maybe a request could be more general, e.g. : what is the
> estimated release date for the microcode updates for fam15 AMD CPUs
> (so a request is not about "opterons only")
>
> On Sun, Feb 18, 2018 at 4:30 AM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
>> They said they would be releasing opteron microcode updates in a few weeks
>> but it has been over a month and I am wondering when this is going to happen
>> or if it already has and I should re-compile coreboot?
>>
>> https://www.amd.com/en/corporate/speculative-execution
>> "We expect to make updates available for our previous generation products
>> over the coming weeks."
>>
>> Thanks!
>>
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
Hi Kyösti
Thanks a lot for the detailed answer!!..
I would never imagine that it was possible to find this schematics on the
internet.
With your answer this start to make much more sense.
I'll spend some time trying to understand everything you said :)
Thanks a lot again!
Rafael Machado
Em sex, 16 de fev de 2018 20:58, Kyösti Mälkki <kyosti.malkki(a)gmail.com>
escreveu:
> Hi Rafael
>
> On Fri, Feb 16, 2018 at 2:03 PM, Rafael Machado
> <rafaelrodrigues.machado(a)gmail.com> wrote:
>
> > The problem is that this time, with this x230, after I connected the
> > postcard and turned the system on, the system stopped to boot. And the
> post
> > card does not stop at a specific post code.
>
> These cheap POST80 displays do not use PCI-e signalling. Looking at
> Wistron Dasher-2 schematics that to my knowledge is (a/the) x230
> mainboard, required LPC signals are not routed to either of the
> mini-PCI-e slots. There is a separate (unpopulated) connector CN14 and
> card-edge GF1 to use for post80 display.
>
> > What happens now, is that every time I turn the system on, the battery
> led
> > blinks 3 times, being two blinks followed by a 1 second stop and after
> that
> > the last blink, and the system reboots.
>
> :(
>
> > The post card I'm using is this:
> >
> https://www.ebay.com/itm/3in1-Mini-PCI-E-PCI-LPC-Tester-PC-Desktop-Diagnost…
>
> I have one these as well. That mini-PCI-e card-edge is not so great,
> it is missing pads for pins 1 and 2. It also appears to be narrower
> what the specs says, so you need to be very careful with proper
> alignment on installation. Also have laptop battery removed while
> doing so!
>
> >
> > So my questions are:
> >
> > -Does someone believe this postcard could have bricked the system? (Why?)
> > -Any idea about how to solve that?
>
> I would measure the 3.3V power rail on the mainboard (VCC3WLAN) . If
> you had installed the postcard improperly/skewed to the socket you
> could have caused some shortcut to GND and damaged the on-board power
> circuitry. Other than that, I don't see how this post card could harm
> a x230.
>
> Hope this helps,
> Kyösti
>
