[Bug other/52885] New: Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[Bug other/52885] New: Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[noloader at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885

             Bug #: 52885
           Summary: Request: Add -aslr switch that invokes -fPIE/-pie or
                    -fPIC/-shared as appropriate
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: other
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: noloader@gmail.com


When writing makefiles or using automake and friends, its currently not
possible to to supply 'generic' set of flags via CFLAGS (or CXXFLAGS) and
produce position independent code and utilize layout randomization.

For example the following will properly setup makefiles for programs, but not
shared objects:

$ configure CFLAGS="-Wall -Wextra -Wconversion -fPIE -pie
    -Wno-unused-parameter -Wformat=2 -Wformat-security
    -fstack-protector-all -Wstrict-overflow
    -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now"

Others have also felt the discomfort:
http://lists.fedoraproject.org/pipermail/devel-announce/2011-August/000821.html.

Please provide a switch that allows us to use position independent code and
layout randomization that works on both programs and shared objects. I suggest
the switch "-aslr" or "-ASLR".

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-04-05 23:34:21 UTC ---
I think this is wrong approach to things.  Basically you should have instead
have an option to automake and friends the support for adding only some flags
for non shared libraries.  

Also using -fPIC instead of -fPIE is always ok.  So I doubt there is a really
issue here.  Since the differences between PIC and PIE comes down to if symbols
are overridable.  PIC is conservative at optimizing.

Also how can you tell the difference between compiling for executable and
shared library if you don't supply -fPIC?  So adding -aslr is not going to be
useful really.

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-04-24 04:03:38 UTC ---
GCC is not a mind reader.  There is no way for GCC to know if you want to do
PIC or PIE code.

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[noloader at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885

--- Comment #3 from Jeffrey Walton <noloader at gmail dot com> 2012-04-24 04:32:35 UTC ---
(In reply to comment #2)
> GCC is not a mind reader.
I kind of knew that.

> There is no way for GCC to know if you want to do
> PIC or PIE code.
Forgive my ignorance, but why does it matter at the code generation stage? How
are relocations different in the object code of a program versus a shared
object? At code generation, I did not think there was even the concept of
program or shared object.

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[noloader at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885

--- Comment #4 from Jeffrey Walton <noloader at gmail dot com> 2012-04-24 04:34:42 UTC ---
(In reply to comment #1)
> 
> Also how can you tell the difference between compiling for executable and
> shared library if you don't supply -fPIC?  So adding -aslr is not going to be
> useful really.
The compiler driver would make the determination at link time, and pass the
appropriate switch to the linker. I did not think it was a difficult concept.
My apologies.

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-04-24 04:35:57 UTC ---
>Forgive my ignorance, but why does it matter at the code generation stage? 

Easy.  With PIE, global variables and functions are considered to bind local
while with PIC they are considered to bind globally (aka override able).


>At code generation, I did not think there was even the concept of program or shared object.

And this is where you are wrong.  GCC has a concept of program vs shared
library.

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[noloader at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885

--- Comment #6 from Jeffrey Walton <noloader at gmail dot com> 2012-04-24 04:38:54 UTC ---
(In reply to comment #5)

> >At code generation, I did not think there was even the concept of program or shared object.
> 
> And this is where you are wrong.  GCC has a concept of program vs shared
> library.
My apologies. I was not aware that object code had a gender (program versus
shared object).

[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate

[noloader at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885

--- Comment #7 from Jeffrey Walton <noloader at gmail dot com> 2012-08-21 22:08:38 UTC ---
(In reply to comment #1)

> Also using -fPIC instead of -fPIE is always ok.  So I doubt there is a really
> issue here.  Since the differences between PIC and PIE comes down to if symbols
> are overridable.  PIC is conservative at optimizing.


-fPIC/-pic apparently breaks other GNU tools:

./configure CFLAGS="-Wall -Wextra -Wconversion -fPIC -pic
-Wno-unused-parameter -Wformat=2 -Wformat-security
-fstack-protector-all -Wstrict-overflow -Wl,-z,noexecstack
-Wl,-z,relro -Wl,-z,now"
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/jeffrey/sipwitch-1.3.1':
configure: error: C compiler cannot create executables
See `config.log' for more details