[Bug binutils/21440] Malicious PE with invalid extended relocation can cause binutils/objdumo 2.28 to allocate any-size big memory
https://sourceware.org/bugzilla/show_bug.cgi?id=21440 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39ff1b79f687b65f4144ddb379f22587003443fb commit 39ff1b79f687b65f4144ddb379f22587003443fb Author: Nick Clifton Date: Tue May 2 11:54:53 2017 +0100 Prevent memory exhaustion from a corrupt PE binary with an overlarge number of relocs. PR 21440 * objdump.c (dump_relocs_in_section): Check for an excessive number of relocs before attempting to dump them. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21440] Malicious PE with invalid extended relocation can cause binutils/objdumo 2.28 to allocate any-size big memory
https://sourceware.org/bugzilla/show_bug.cgi?id=21440 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #3 from Nick Clifton --- Thanks for reporting this bug. I have applied a patch to add a check for the reloc size being larger than the size of the file, and hence invalid, before an attempt is made to allocate memory for the relocs. I think that this should resolve the problem. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21448] References to constant data in shared libraries bloats 2.28 executables compared to 2.27
https://sourceware.org/bugzilla/show_bug.cgi?id=21448 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amodra at gmail dot com Resolution|--- |WONTFIX --- Comment #2 from Alan Modra --- This is not a ld problem. The patch for pr20995 is a necessary security fix. The real reason you are seeing larger binaries is that gcc is using copy relocs rather than accessing the shared library variables, in order to gain a small performance improvement. Please open a gcc bug. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21128] i386: FAIL: icf_safe_so_test.sh
https://sourceware.org/bugzilla/show_bug.cgi?id=21128
H.J. Lu changed:
What|Removed |Added
CC||ccoutant at gmail dot com,
||tmsriram at google dot com
--- Comment #1 from H.J. Lu ---
icf_safe_so_test.cc has
---
// The goal of this program is to verify if identical code folding
// in safe mode correctly folds functions in a shared object. The
// foo_* functions below should not be folded on X86_64.
// For 32-bit X86, the hidden protected and internal symbols can be folded.
// foo_glob and bar_glob should not be folded, because function pointer
// of foo_glob is taken.
int __attribute__ ((visibility ("protected")))
foo_prot()
{
return 1;
}
int __attribute__ ((visibility ("hidden")))
foo_hidden()
{
return 1;
}
int __attribute__ ((visibility ("internal")))
foo_internal()
{
return 1;
}
static int
foo_static()
{
return 1;
}
int foo_glob()
{
return 2;
}
int bar_glob()
{
return 2;
}
int main()
{
int (*p)() = foo_glob;
(void)p;
foo_static();
foo_prot();
foo_hidden();
foo_internal();
return 0;
}
---
I don't see why foo_hidden, foo_internal and foo_prot can't be folded for
x86-64.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21128] i386: FAIL: icf_safe_so_test.sh
https://sourceware.org/bugzilla/show_bug.cgi?id=21128
--- Comment #2 from H.J. Lu ---
[hjl@gnu-6 pr21128]$ cat x.c
static int
foo_static_0()
{
return 1;
}
static int
foo_static_1()
{
return 1;
}
int main()
{
foo_static_0();
foo_static_1();
return 0;
}
[hjl@gnu-6 pr21128]$ make
gcc -ffunction-sections -c -o x.o x.c
./ld --icf=safe -Map x.map -o x x.o
./ld -shared --icf=safe -Map x.so.map -o x.so x.os
[hjl@gnu-6 pr21128]$ head -10 x.map
Discarded input sections
.text.foo_static_1
0x0xb x.o
.note.GNU-stack
0x0x0 x.o
Memory map
[hjl@gnu-6 pr21128]$ head -10 x.so.map
Discarded input sections
.note.GNU-stack
0x0x0 x.os
Memory map
** file header
0x 0x40
[hjl@gnu-6 pr21128]$
Why can't foo_static_0 and foo_static_1 be folded in a shared object?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21384] symbols defined with --dynamic-list missing in output binary
https://sourceware.org/bugzilla/show_bug.cgi?id=21384 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=73ec947d59c511411377ad51ef792a5fcdd3f0cc commit 73ec947d59c511411377ad51ef792a5fcdd3f0cc Author: Alan Modra Date: Tue May 2 21:56:43 2017 +0930 PR 21384, --dynamic-list regression with f02cb058 The commit to "Always descend into output section statements in lang_do_assignments" meant that linker script symbols were not bfd_link_hash_new when ld called bfd_elf_record_link_assignment. This patch corrects that problem by testing h->non_elf instead. PR 21384 * elflink.c (bfd_elf_link_mark_dynamic_symbol): Test h->non_elf rather than h->root.type == bfd_link_hash_new. (bfd_elf_record_link_assignment): Similarly, call bfd_elf_link_mark_dynamic_symbol when h->non_elf. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21429] objdump -d generate not good value in comment
https://sourceware.org/bugzilla/show_bug.cgi?id=21429 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |INVALID --- Comment #1 from Nick Clifton --- Hi Linyu, > when i use objdump in binutils 2.26 to dump a ARM image, > I saw value in comment is not good, some are errors. > > check below asm code, > c009a8: e3e03afemvn r3, #1040384; 0xfe000 > c009ac: e50320efstr r2, [r3, #-239] ; 0xff11 > c009b0: e50320ebstr r2, [r3, #-235] ; 0xff15 > c009b4: e50320e7str r2, [r3, #-231] ; 0xff19 > c009b8: e50320e3str r2, [r3, #-227] ; 0xff1d Ah - no - the comments are correct. It is just that they are not telling you the result of the address computation, they are telling you the hex value of the constants encoded in the instructions. The intent is that knowing the hex value may be useful in understanding the purpose of the instruction. The reason that the comment does not show the full address computation is that the address cannot be known. Just because the instructions occur in a sequence it does not mean that one of them might be the target of a branch. So the contents of the R3 register cannot be known reliably. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21128] i386: FAIL: icf_safe_so_test.sh
https://sourceware.org/bugzilla/show_bug.cgi?id=21128
--- Comment #3 from H.J. Lu ---
ICF in shared object is disabled for x86-64 on purpose. But on i386, both
foo_hidden and foo_internal are folded into foo_prot. Because of
if (length(act[0]) == 0 || length(act[1]) == 0)
{
printf \"Safe Identical Code Folding did not fold $2 and $3\\n\"
exit 1;
}
we got the false error.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21452] New: Enable safe ICF for shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=21452
Bug ID: 21452
Summary: Enable safe ICF for shared object
Product: binutils
Version: 2.29 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: hjl.tools at gmail dot com
CC: ian at airs dot com, rahulchaudhry at chromium dot org,
tmsriram at google dot com
Target Milestone: ---
Target: x86-64
x86-64.cc has
template
inline bool
Target_x86_64::Scan::local_reloc_may_be_function_pointer(
Symbol_table* ,
Layout* ,
Target_x86_64* ,
Sized_relobj_file* src_obj,
unsigned int src_indx,
Output_section* ,
const elfcpp::Rela& reloc,
unsigned int r_type,
const elfcpp::Sym&)
{
// When building a shared library, do not fold any local symbols as it is
// not possible to distinguish pointer taken versus a call by looking at
// the relocation types.
if (parameters->options().shared())
return true;
return possible_function_pointer_reloc(src_obj, src_indx,
reloc.get_r_offset(), r_type);
}
// For safe ICF, scan a relocation for a global symbol to check if it
// corresponds to a function pointer being taken. In that case mark
// the function whose pointer was taken as not foldable.
template
inline bool
Target_x86_64::Scan::global_reloc_may_be_function_pointer(
Symbol_table*,
Layout* ,
Target_x86_64* ,
Sized_relobj_file* src_obj,
unsigned int src_indx,
Output_section* ,
const elfcpp::Rela& reloc,
unsigned int r_type,
Symbol* gsym
{
// When building a shared library, do not fold symbols whose visibility
// is hidden, internal or protected.
if (parameters->options().shared()
&& (gsym->visibility() == elfcpp::STV_INTERNAL
|| gsym->visibility() == elfcpp::STV_PROTECTED
|| gsym->visibility() == elfcpp::STV_HIDDEN))
return true;
return possible_function_pointer_reloc(src_obj, src_indx,
reloc.get_r_offset(), r_type);
}
With
commit 4aebb6312eb5dcd12f2f8420028547584b708907
Author: Rahul Chaudhry
Date: Wed Feb 15 00:37:10 2017 -0800
Improved support for --icf=safe when used with -pie.
gold/
* x86_64.cc (Target_x86_64::do_can_check_for_function_pointers):
Return true even when building pie binaries.
(Target_x86_64::possible_function_pointer_reloc): Check opcode
for R_X86_64_PC32 relocations.
(Target_x86_64::local_reloc_may_be_function_pointer): Pass
extra arguments to local_reloc_may_be_function_pointer.
(Target_x86_64::global_reloc_may_be_function_pointer): Likewise.
* gc.h (gc_process_relocs): Add check for STT_FUNC.
* testsuite/Makefile.am (icf_safe_pie_test): New test case.
* testsuite/Makefile.in: Regenerate.
* testsuite/icf_safe_pie_test.sh: New shell script.
we now check opcode with R_X86_64_PC32 relocation, which tell branches from
function pointers. We should enable safe ICF for shared object on x86-64.
Also, global symbols with non-default visibility should be folded like local
symbols.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21453] New: Safe ICF doesn't work with -fno-plt
https://sourceware.org/bugzilla/show_bug.cgi?id=21453
Bug ID: 21453
Summary: Safe ICF doesn't work with -fno-plt
Product: binutils
Version: 2.29 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: hjl.tools at gmail dot com
CC: ian at airs dot com, rahulchaudhry at chromium dot org,
tmsriram at google dot com
Target Milestone: ---
Target: i386, x86_64
When fno-plt is used, GOT relocation will be used to call external functions:
:
0: 8d 4c 24 04 lea0x4(%esp),%ecx
4: 83 e4 f0and$0xfff0,%esp
7: ff 71 fcpushl -0x4(%ecx)
a: 55 push %ebp
b: 89 e5 mov%esp,%ebp
d: 53 push %ebx
e: 51 push %ecx
f: 83 ec 10sub$0x10,%esp
12: e8 fc ff ff ff call 1313: R_386_PC32
__x86.get_pc_thunk.bx
17: 81 c3 02 00 00 00 add$0x2,%ebx19: R_386_GOTPC
_GLOBAL_OFFSET_TABLE_
1d: 8b 83 00 00 00 00 mov0x0(%ebx),%eax 1f: R_386_GOT32X
foo_glob
23: 89 45 f4mov%eax,-0xc(%ebp)
26: ff 93 00 00 00 00 call *0x0(%ebx) 28: R_386_GOT32X
bar_glob
2c: ff 93 00 00 00 00 call *0x0(%ebx) 2e: R_386_GOT32X
foo_normal
32: ff 93 00 00 00 00 call *0x0(%ebx) 34: R_386_GOT32X
foo_default
38: b8 00 00 00 00 mov$0x0,%eax
3d: 83 c4 10add$0x10,%esp
40: 59 pop%ecx
41: 5b pop%ebx
42: 5d pop%ebp
43: 8d 61 fclea-0x4(%ecx),%esp
46: c3 ret
Gold needs to check opcode for branches to enable safe ICF:
[hjl@gnu-6 gold-1]$ cat x.c
extern int foo_normal(void);
extern int foo_default(void);
extern int foo_glob(void);
extern int bar_glob(void);
int main()
{
int (*p)() = foo_glob;
(void)p;
bar_glob ();
foo_normal();
foo_default();
return 0;
}
[hjl@gnu-6 gold-1]$ cat y.c
int
foo_normal(void)
{
return 1;
}
int
foo_default(void)
{
return 1;
}
int foo_glob(void)
{
return 2;
}
int bar_glob(void)
{
return 2;
}
[hjl@gnu-6 gold-1]$ make x
/export/build/gnu/gcc-7/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-7/build-x86_64-linux/gcc/ -m32 -c -fPIE
-ffunction-sections -fno-plt -o x.o x.c
/export/build/gnu/gcc-7/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-7/build-x86_64-linux/gcc/ -m32 -c -fPIE
-ffunction-sections -fno-plt -o y.o y.c
./ld -pie --icf=safe -Map x.map -m elf_i386 -o x x.o y.o
[hjl@gnu-6 gold-1]$ cat x.map
Discarded input sections
.group 0x0x8 x.o
.note.GNU-stack
0x0x0 x.o
.group 0x0x8 y.o
.note.GNU-stack
0x0x0 y.o
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21384] symbols defined with --dynamic-list missing in output binary
https://sourceware.org/bugzilla/show_bug.cgi?id=21384 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=640226f048b67d79da85742728e40114c9ee5da0 commit 640226f048b67d79da85742728e40114c9ee5da0 Author: H.J. Lu Date: Tue May 2 13:54:22 2017 -0700 Add a test for PR ld/21384 PR ld/21384 * testsuite/ld-elf/pr21384.d: New file. * testsuite/ld-elf/pr21384.dl: Likewise. * testsuite/ld-elf/pr21384.ld: Likewise. * testsuite/ld-elf/pr21384.s: Likewise. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21384] symbols defined with --dynamic-list missing in output binary
https://sourceware.org/bugzilla/show_bug.cgi?id=21384 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amodra at gmail dot com Resolution|--- |FIXED Assignee|unassigned at sourceware dot org |amodra at gmail dot com Target Milestone|--- |2.29 --- Comment #3 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21448] References to constant data in shared libraries bloats 2.28 executables compared to 2.27
https://sourceware.org/bugzilla/show_bug.cgi?id=21448 --- Comment #3 from Michael Deutschmann --- GCC (6.3.0) doesn't seem to be doing anything magical in the .s files. It looks like the behavior is triggered only by a ".size" directive on the shared library side, and ".size" isn't documented to have any implications regarding "copy relocs". On the executable side, the behavior is triggered by the simplest reference to the big object's address, even in an entirely handwritten .s file. Also, it would seem binutils could avoid the bloat by making the ".data.rel.ro" section like BSS, as it seems to only include zeros. This would mean adding one more LOAD segment to an ELF executable (with zero filesize and substantial memsize); therefore it would be a reasonable space-optimization to do it the 2.28 way if the .data.rel.ro has fewer bytes than one ELF p-header. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
