Re: [PATCH] RISC-V: Add initial return value location support.
On Thu, 2018-12-27 at 15:26 -0800, Jim Wilson wrote:
> Started with the aarch64 support and modified it for RISC-V. The
> flattened
> structure support hasn't been written yet, but the rest of it should
> be
> correct for the LP64D ABI. We have potentially 6 different ABIs to
> support,
> so this requires checking elf header flags in riscv_init when setting
> the hook.
nitpick. Please keep the commit message lines < 76 chars if possible.
Looks good and it resolves the run-native-test.sh (on risc-v).
We really should add a non-native test, so it is easier to test on
other arches. But currently only aarch64 has one (run-funcretval.sh).
I'll see if I can extend that to other arches. Then we can also see if
we can get the aggregates correct.
The comments explain things well, but it would be good to have official
references to the calling convention and DWARF register mappings.
The calling convention is explained in:
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#procedure-calling-convention
But I couldn't find an official DWARF register mapping.
If you have references I like to add them to the code.
Pushed as is.
Thanks,
Mark
BTW. Just for other reviewers.
> +static int
> +pass_in_gpr_lp64 (const Dwarf_Op **locp, Dwarf_Word size)
> +{
> + static const Dwarf_Op loc[] =
> +{
> + { .atom = DW_OP_reg10 }, { .atom = DW_OP_piece, .number = 8 },
> + { .atom = DW_OP_reg11 }, { .atom = DW_OP_piece, .number = 8 }
> +};
> +
> + *locp = loc;
> + return size <= 8 ? 1 : 4;
> +}
Other backends also do this, but it might not be immediately clear (at
least I had to double check). When the size fits into a register we
pretend that the returned loc description is simply of size 1
(DW_OP_reg10), otherwise it is split across the two registers (size 4,
two pieces).
[Bug libelf/24081] New: Use-After-free Problem in elf32_xlatetom function in libelf
https://sourceware.org/bugzilla/show_bug.cgi?id=24081 Bug ID: 24081 Summary: Use-After-free Problem in elf32_xlatetom function in libelf Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libelf Assignee: unassigned at sourceware dot org Reporter: wcventure at 126 dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 11527 --> https://sourceware.org/bugzilla/attachment.cgi?id=11527&action=edit POC1 Hi there, Our fuzzer caught Use-after-free problem in eu-readelf of the latest elfutils-0.174 code base when calling memmove in elf32_xlatetom function in libelf, this inputs will cause the segment faults and I have confirmed them with address sanitizer too. Please use the "./eu-readelf -a $POC"to reproduce the bug. If you have any questions, please let me know. git log > commit 1dabad36ee28aa76b8cf14b6426b379cabee6def > Author: Jim Wilson > Date: Thu Dec 27 15:25:49 2018 -0800 > > RISC-V: Improve riscv64 core file support. > > This fixes two problems. The offset for x1 is changed from 1 to 8 because > this is a byte offset not a register skip count. Support for reading the > PC value is added. This requires changing the testsuite to match the new > readelf output for coredumps. > > Signed-off-by: Jim Wilson The ASAN dumps the stack trace as follows: > ==7822==ERROR: AddressSanitizer: unknown-crash on address 0x7f773670a000 at > pc 0x7f7735694e2b bp 0x7ffcba3c16a0 sp 0x7ffcba3c0e48 > READ of size 8 at 0x7f773670a000 thread T0 > #0 0x7f7735694e2a in memmove > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x7ae2a) > #1 0x7f7734d5a9bb in memmove > /usr/include/x86_64-linux-gnu/bits/string3.h:59 > #2 0x7f7734d5a9bb in elf32_xlatetom /elfutils/libelf/elf32_xlatetom.c:100 > #3 0x56d6b8 in ebl_object_note /elfutils/libebl/eblobjnote.c:342 > #4 0x4a06f3 in handle_notes_data /elfutils/src/readelf.c:12251 > #5 0x4c5b47 in handle_notes /elfutils/src/readelf.c:12315 > #6 0x4c5b47 in process_elf_file /elfutils/src/readelf.c:1000 > #7 0x4c5b47 in process_dwflmod /elfutils/src/readelf.c:760 > #8 0x7f7735265e9c in dwfl_getmodules > /elfutils/libdwfl/dwfl_getmodules.c:86 > #9 0x41399c in process_file /elfutils/src/readelf.c:868 > #10 0x405df6 in main /elfutils/src/readelf.c:350 > #11 0x7f773477b82f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > #12 0x406ef8 in _start (/elfutils/build/bin/eu-readelf+0x406ef8) > > Address 0x7f773670a000 is a wild pointer. > SUMMARY: AddressSanitizer: unknown-crash > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x7ae2a) in memmove > Shadow bytes around the buggy address: > 0x0fef66cd93b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fef66cd93c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fef66cd93d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fef66cd93e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fef66cd93f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > =>0x0fef66cd9400:[fe]fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe > 0x0fef66cd9410: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe > 0x0fef66cd9420: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe > 0x0fef66cd9430: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe > 0x0fef66cd9440: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe > 0x0fef66cd9450: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user:f7 > Container overflow: fc > Array cookie:ac > Intra object redzone:bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone:cb > ==7822==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/24081] Use-After-free Problem in elf32_xlatetom function in libelf
https://sourceware.org/bugzilla/show_bug.cgi?id=24081 --- Comment #1 from wcventure --- Created attachment 11528 --> https://sourceware.org/bugzilla/attachment.cgi?id=11528&action=edit POC2 -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] RISC-V: Add initial return value location support.
On Thu, Jan 10, 2019 at 4:26 AM Mark Wielaard wrote: > The comments explain things well, but it would be good to have official > references to the calling convention and DWARF register mappings. > The calling convention is explained in: > > https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#procedure-calling-convention > But I couldn't find an official DWARF register mapping. > If you have references I like to add them to the code. There is an issue asking us to add DWARF register mappings. This was filed before gdb was upstream and so some the comments are out of date, but most of the info is still correct. https://github.com/riscv/riscv-elf-psabi-doc/issues/70 I guess I should put that on my to do list to finish this now. Jim
Re: [PATCH] RISC-V: Add initial return value location support.
On Thu, Jan 10, 2019 at 4:26 AM Mark Wielaard wrote: > We really should add a non-native test, so it is easier to test on > other arches. But currently only aarch64 has one (run-funcretval.sh). > I'll see if I can extend that to other arches. Then we can also see if > we can get the aggregates correct. RISC-V will require additional types for full coverage. I've been adding extra types to my local copy of the testcase .c file as I implement them, but I still have a ways to go before this is finished, and a few too many things on my to do list. Jim
[Bug backends/24084] New: Negative-size-param when when calling memcpy function in elf_cvt_note function in libelf the latest elfutils-0.174 code base, this inputs will cause the segment faults and I
https://sourceware.org/bugzilla/show_bug.cgi?id=24084 Bug ID: 24084 Summary: Negative-size-param when when calling memcpy function in elf_cvt_note function in libelf the latest elfutils-0.174 code base, this inputs will cause the segment faults and I have confirmed them with address sanitizer too. Please use the ".//eu-elflint - Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: backends Assignee: unassigned at sourceware dot org Reporter: wcventure at 126 dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 11530 --> https://sourceware.org/bugzilla/attachment.cgi?id=11530&action=edit POC Hi there, Negative-size-param when calling memcpy function in elf_cvt_note function in libelf the latest elfutils-0.174 code base, this inputs will cause the segment faults and I have confirmed them with address sanitizer too. Please use the ".//eu-elflint -d $POC"to reproduce the bug. If you have any questions, please let me know. git log > commit 1dabad36ee28aa76b8cf14b6426b379cabee6def > Author: Jim Wilson > Date: Thu Dec 27 15:25:49 2018 -0800 > > RISC-V: Improve riscv64 core file support. > > This fixes two problems. The offset for x1 is changed from 1 to 8 because > this is a byte offset not a register skip count. Support for reading the > PC value is added. This requires changing the testsuite to match the new > readelf output for coredumps. > > Signed-off-by: Jim Wilson The ASAN dumps the stack trace as follows: > = > ==24780==ERROR: AddressSanitizer: negative-size-param: (size=-4) > #0 0x7f23f4234853 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79853) > #1 0x7f23f3edaa2c in memcpy > /usr/include/x86_64-linux-gnu/bits/string3.h:53 > #2 0x7f23f3edaa2c in elf_cvt_note /elfutils/libelf/note_xlate.h:63 > #3 0x7f23f3edaa2c in elf_cvt_note4 /elfutils/libelf/note_xlate.h:79 > #4 0x7f23f3f2ed30 in convert_data /elfutils/libelf/elf_getdata.c:204 > #5 0x7f23f3f2ed30 in __libelf_set_data_list_rdlock > /elfutils/libelf/elf_getdata.c:447 > #6 0x7f23f3f301bf in __elf_getdata_rdlock > /elfutils/libelf/elf_getdata.c:554 > #7 0x469a22 in check_note_section /elfutils/src/elflint.c:4428 > #8 0x469a22 in check_sections /elfutils/src/elflint.c:4182 > #9 0x47a222 in process_elf_file /elfutils/src/elflint.c:4774 > #10 0x47a222 in process_file /elfutils/src/elflint.c:242 > #11 0x4030d5 in main /elfutils/src/elflint.c:175 > #12 0x7f23f38d182f in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) > #13 0x404718 in _start (/elfutils/build/bin/eu-elflint+0x404718) > > Address 0x7f23f52b3b30 is a wild pointer. > SUMMARY: AddressSanitizer: negative-size-param > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79853) > ==24780==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/24084] Negative-size-param when when calling memcpy function in elf_cvt_note function in libelf
https://sourceware.org/bugzilla/show_bug.cgi?id=24084 wcventure changed: What|Removed |Added Summary|Negative-size-param when|Negative-size-param when |when calling memcpy |when calling memcpy |function in elf_cvt_note|function in elf_cvt_note |function in libelf the |function in libelf |latest elfutils-0.174 code | |base, this inputs will | |cause the segment faults| |and I have confirmed them | |with address sanitizer too. | | Please use the| |".//eu-elflint -| -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/24085] New: An Out of Memory problem was discovered in function in read_long_names in elf_begin.c in libelf
https://sourceware.org/bugzilla/show_bug.cgi?id=24085 Bug ID: 24085 Summary: An Out of Memory problem was discovered in function in read_long_names in elf_begin.c in libelf Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libelf Assignee: unassigned at sourceware dot org Reporter: wcventure at 126 dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 11531 --> https://sourceware.org/bugzilla/attachment.cgi?id=11531&action=edit POC Hi, there. We test the program at the master branch. An Out of Memory problem was discovered in function in read_long_names in elf_begin.c in libelf. The program tries to allocate with a large number size(44454912 bytes) of memory. $git log > commit 1dabad36ee28aa76b8cf14b6426b379cabee6def > Author: Jim Wilson > Date: Thu Dec 27 15:25:49 2018 -0800 > > RISC-V: Improve riscv64 core file support. > > This fixes two problems. The offset for x1 is changed from 1 to 8 because > this is a byte offset not a register skip count. Support for reading the > PC value is added. This requires changing the testsuite to match the new > readelf output for coredumps. > > Signed-off-by: Jim Wilson The ASAN dumps the stack trace as follows: > ==10165==ERROR: AddressSanitizer failed to allocate 0x677af43000 > (44454912) bytes of LargeMmapAllocator (error code: 12) > ==10165==Process memory map follows: > 0x0040-0x0043 > /home/wencheng/Experiment/elfutils/build/bin/eu-ar > 0x0062f000-0x0063 > /home/wencheng/Experiment/elfutils/build/bin/eu-ar > 0x0063-0x00633000 > /home/wencheng/Experiment/elfutils/build/bin/eu-ar > 0x7fff7000-0x8fff7000 > 0x8fff7000-0x02008fff7000 > 0x02008fff7000-0x10007fff8000 > 0x6000-0x6020 > 0x6020-0x6021 > 0x6021-0x602e > 0x602e-0x602e0001 > 0x602e0001-0x6040 > 0x6040-0x6041 > 0x6041-0x604e > 0x604e-0x604e0001 > 0x604e0001-0x6060 > 0x6060-0x6061 > 0x6061-0x606e > 0x606e-0x606e0001 > 0x606e0001-0x6070 > 0x6070-0x6071 > 0x6071-0x607e > 0x607e-0x607e0001 > 0x607e0001-0x6080 > 0x6080-0x6081 > 0x6081-0x608e > 0x608e-0x608e0001 > 0x608e0001-0x60b0 > 0x60b0-0x60b1 > 0x60b1-0x60be > 0x60be-0x60be0001 > 0x60be0001-0x60c0 > 0x60c0-0x60c1 > 0x60c1-0x60ce > 0x60ce-0x60ce0001 > 0x60ce0001-0x60f0 > 0x60f0-0x60f1 > 0x60f1-0x60fe > 0x60fe-0x60fe0001 > 0x60fe0001-0x6100 > 0x6100-0x6101 > 0x6101-0x610e > 0x610e-0x610e0001 > 0x610e0001-0x6110 > 0x6110-0x6111 > 0x6111-0x611e > 0x611e-0x611e0001 > 0x611e0001-0x6120 > 0x6120-0x6121 > 0x6121-0x612e > 0x612e-0x612e0001 > 0x612e0001-0x6140 > 0x6140-0x6141 > 0x6141-0x614e > 0x614e-0x614e0001 > 0x614e0001-0x6180 > 0x6180-0x6181 > 0x6181-0x618e > 0x618e-0x618e0001 > 0x618e0001-0x6190 > 0x6190-0x6191 > 0x6191-0x619e > 0x619e-0x619e0001 > 0x619e0001-0x61a0 > 0x61a0-0x61a1 > 0x61a1-0x61ae > 0x61ae-0x61ae0001 > 0x61ae0001-0x6240 > 0x6240-0x6241 > 0x6241-0x624e > 0x624e-0x624e0001 > 0x624e0001-0x6400 > 0x6400-0x64003000 > 0x7f18aa227000-0x7f18aa50 /usr/lib/locale/locale-archive > 0x7f18aa50-0x7f18aa60 > 0x7f18aa70-0x7f18aa80 > 0x7f18aa90-0x7f18aaa0 > 0x7f18aab0-0x7f18aac0 > 0x7f18aac59000-0x7f18acfab000
[Bug libelf/24085] An Out of Memory problem was discovered in function in read_long_names in elf_begin.c in libelf
https://sourceware.org/bugzilla/show_bug.cgi?id=24085 --- Comment #1 from wcventure --- Please use the "./eu-ar -tv $POC" to reproduce the bug. If you have any questions, please let me know. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24086] New: Multiple memory leak issues were discovered in in libelf and libdwelf
https://sourceware.org/bugzilla/show_bug.cgi?id=24086 Bug ID: 24086 Summary: Multiple memory leak issues were discovered in in libelf and libdwelf Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: general Assignee: unassigned at sourceware dot org Reporter: wcventure at 126 dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 11532 --> https://sourceware.org/bugzilla/attachment.cgi?id=11532&action=edit POC Hi there, We have discover lots of memory leak in libelf and libdwelf. Multiple memory leak issues were discovered in libelf and libdwelf, as distributed in Elfutils 0.174. There are many heap allocations. But these heap allocations didn't deallocate in the end. Please use the "./eu-strip $POC" to reproduce the bug. The ASAN dumps the stack trace as follows: > = > ==22066==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 6712 byte(s) in 1 object(s) allocated from: > #0 0x7f3aeabb6d78 in __interceptor_calloc > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded78) > #1 0x7f3aea8b5a38 in allocate_elf > /home/wencheng/Experiment/elfutils/libelf/common.h:74 > #2 0x7f3aea8b5a38 in elf_clone > /home/wencheng/Experiment/elfutils/libelf/elf_clone.c:56 > > Direct leak of 96 byte(s) in 1 object(s) allocated from: > #0 0x7f3aeabb6d78 in __interceptor_calloc > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded78) > #1 0x7f3aea39b1b2 in dwelf_strtab_init > /home/wencheng/Experiment/elfutils/libdwelf/dwelf_strtab.c:94 > #2 0x44406d in process_file > /home/wencheng/Experiment/elfutils/src/strip.c:769 > > Indirect leak of 4080 byte(s) in 1 object(s) allocated from: > #0 0x7f3aeabb6b90 in __interceptor_malloc > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb90) > #1 0x7f3aea39a787 in morememory > /home/wencheng/Experiment/elfutils/libdwelf/dwelf_strtab.c:120 > #2 0x7f3aea39a787 in newstring > /home/wencheng/Experiment/elfutils/libdwelf/dwelf_strtab.c:161 > #3 0x7f3aea39a787 in strtab_add > /home/wencheng/Experiment/elfutils/libdwelf/dwelf_strtab.c:221 > > Indirect leak of 1120 byte(s) in 28 object(s) allocated from: > #0 0x7f3aeabb6d78 in __interceptor_calloc > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded78) > #1 0x7f3aea82ab3e in elf_newscn > /home/wencheng/Experiment/elfutils/libelf/elf_newscn.c:125 > > Indirect leak of 288 byte(s) in 1 object(s) allocated from: > #0 0x7f3aeabb6f80 in realloc > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdef80) > #1 0x7f3aea812223 in elf32_newphdr > /home/wencheng/Experiment/elfutils/libelf/elf32_newphdr.c:134 > > Indirect leak of 240 byte(s) in 1 object(s) allocated from: > #0 0x7f3aeabb6b90 in __interceptor_malloc > (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb90) > #1 0x7f3aea39bd0c in dwelf_strtab_finalize > /home/wencheng/Experiment/elfutils/libdwelf/dwelf_strtab.c:322 > #2 0x7f3aea56c2bf > (/home/wencheng/Experiment/elfutils/build/lib/libdw.so.1+0x3852bf) > > SUMMARY: AddressSanitizer: 12536 byte(s) leaked in 33 allocation(s). -- You are receiving this mail because: You are on the CC list for the bug.
