Bug 52885 - Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
Summary: Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropr...
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.6.1
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-05 23:18 UTC by Jeffrey Walton
Modified: 2012-08-21 22:08 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeffrey Walton 2012-04-05 23:18:20 UTC
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".
Comment 1 Andrew Pinski 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.
Comment 2 Andrew Pinski 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.
Comment 3 Jeffrey Walton 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.
Comment 4 Jeffrey Walton 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.
Comment 5 Andrew Pinski 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.
Comment 6 Jeffrey Walton 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).
Comment 7 Jeffrey Walton 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