PIE / PIC in a nutshell (was: [PATCH] use -pie in CFLAGS)

[Peter Samuelson <pe...@p12n.org>]

[Branko Cibej]
> On the other hand, I'd like to hear a bit more about why we'd want to
> use -fpie, apart from that "security people" like it.

To understand PIE you must understand PIC....

PIC (position-independent code) lets you share memory-mapped executable
code between processes without hard-coding the address space location.
Shared libraries use PIC so that all instances of the library in all
running processes can use a single copy of the library code in RAM.
This technique is used on most Unix systems, though I _believe_ Windows
DLLs are not PIC and are not shared in memory.

The disadvantage of PIC is that the code itself is somewhat less
efficient, since you have to use lookup tables and registers everywhere
instead of hard-coded addresses.  Even so, sharing your RAM between
processes is enough of a win that most people build all shared
libraries as PIC.

Executables don't need to be PIC because you can just hard-code the
address space of the executable code, at link time.  You can't easily
do that for the libraries since they're used by multiple
executables.[1]

  [1] Well, you can.  OSF/1 and perhaps other systems used to get
      around this, without PIC, by having a global address space
      allocation scheme that the linker could use, and update, each
      time you build a new system library.  (It helps to have a 64-bit
      address space to play in.)  But this system was something of a
      pain to use, because the allocation file was owned by root, so
      you had to 'su' in order to update it for your newly built
      library.  Nobody's build systems ever seemed to do this
      automatically in 'make install', of course.

There's a secondary benefit to PIC in the security world: address space
randomization.  Basically, if you can map your code to random locations
each time you start a process, most stack smashing security attacks
become infeasible, because the attacker generally has to have an
educated guess how to jump to, for example, the system() function.

If you want full address space randomization at runtime, foiling a
large class of security attacks, you can build your executables as PIC
... but the efficiency cost is high enough to be unpalatable.  Which
brings us to PIE, position-independent executables.  PIE provides
position independence without most of the cost of PIC.  PIE only works
for executables, not shared libraries, so PIC is still used for the
latter.

Note, you still need an OS runtime that supports address space
randomization, in order for PIE to be of much practical benefit.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: PIE / PIC in a nutshell

[Branko Čibej <br...@xbc.nu>]

Peter Samuelson wrote:
> [Branko Cibej]
>   
>> On the other hand, I'd like to hear a bit more about why we'd want to
>> use -fpie, apart from that "security people" like it.
>>     
>
> To understand PIE you must understand PIC....
>   

Aargh. I know what PIE does, and I know what PIC does, and I'm still 
asking: Why would we want to use -fpie in the default compiler flags, 
given that said flags can be easily overriden on any system that 
supports -fpie?

In other words, if some security-enhanced Linux distro wants to use 
-fpie all over the place, well and good. Nobody's stopping them.

-- Brane


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org