[Bug ld/21448] References to constant data in shared libraries bloats 2.28 executables compared to 2.27

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21448

--- Comment #8 from Alan Modra  ---
OK, it's still true that the fix for pr20995 is necessary for security.  Also,
making the linker generated .data.rel.ro section BSS won't help disk space
unless you're willing to waste more memory, or you have the linker generated
.data.rel.ro larger than maxpagesize (0x20 for x86_64-linux).

-- 
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/21459] New: Wrong location for .debug_gdb_scripts on Windows

[egonelbre at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21459

Bug ID: 21459
   Summary: Wrong location for .debug_gdb_scripts on Windows
   Product: binutils
   Version: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: egonelbre at gmail dot com
  Target Milestone: ---

While debugging go compilation issue
(https://github.com/golang/go/issues/20183)
we trace it to ld placing .debug_gdb_scripts to a wrong location for Windows.

Easiest test-case:

int main(int argc, char const *argv[]) { return 0; }
__attribute__ ((section(".debug_gdb_scripts")))
char data[] = "debug.py";

  > gcc -o example.exe example.c && example.exe
Access Denied

This also happens when you use any other random .debug_* section... e.g.

int main(int argc, char const *argv[]) { return 0; }
__attribute__ ((section(".debug_zzz")))
char data[] = "debug.py";

Suggestion from Ian Lance Taylor
(https://github.com/golang/go/issues/20183#issuecomment-299167976):

> The GNU linker source files that fail to list the .debug_gdb_scripts 
> section are ld/scripttempl/pe.sc and ld/scripttempl/pep.sc.
> The best fix is to handle this case in gld_${EMULATION_NAME}_place_orphan 
> in ld/emultempl/pe.em and ld/emultempl/pep.em.

-- 
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/21458] ld generates none ARM elf ABI compliant code that causes a hard fault.

[Andrewgoedhart at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21458

Andrew Goedhart  changed:

   What|Removed |Added

 Target||Arm cortex M
 CC||Andrewgoedhart at gmail dot com
   Host||Linux

-- 
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

[michael at talosis dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=21448

--- Comment #9 from Michael Deutschmann  ---
My system is a hobby on old computers, so my pagesize is 4k.

> OK, it's still true that the fix for pr20995 is necessary for security.

You keep saying this, but I don't see how it's a problem that occasional
const-declared data objects might not segfault when the constness is violated. 
Const is more about giving the OS freedom to optimize, and for detecting some
API misuse bugs at compile time.

Seems to me the fact that ".rodata" shares a segment with ".text" is just as
much a flaw, since that means .rodata has an unnecessary execute permission.

What really benefits security is to have no page anywhere that is both writable
and executable.  I see no reason the ".data.rel.ro" stuff will ever need
execute permission, therefore leaving it writable at the machine level to save
some bloat seems harmless.

(Merging .rodata with .text instead of .data makes sense since both .rodata and
.text can be shared with other processes running the same executable. 
.data.rel.ro can't be shared since it is customized at run time.)

-- 
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