Do I need -KPIC -DPIC and -ztype=pie for full ASLR support?

RaiderOfTheLostSPARC

Hi,

do I have to compile my programs with -KPIC -DPIC and -ztype=pie so that -zaslr=enable has any effect?

$ cc -KPIC -DPIC -ztype=pie -zaslr=enable helloworld.c

$ file a.out

a.out: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE], position-independent executable, dynamically linked, not stripped

Also it seems like nothing in the base OS is compiled with PIC/PIE, why is that so?

$ file /usr/bin/* | grep position

$ file /usr/sbin/* | grep position

$

Ali Bahrami-Oracle

The short answer is: Yes, you do.

As you undoubtedly know, ASLR works by altering the mapped addresses of

mapped objects.

ASLR has always been able to work on the shared objects in a process, because

shared objects are ET_DYN, built to be mapped at arbitrary addresses. Shared

objects should always be built PIC, because otherwise, they end up containing code

that needs to be fixed up at load time, imposing unnecessary startup costs.

ASLR has traditionally not able to work on the main "a.out" object, because such

objects were built as ET_EXEC, fixed to a known address.  The initial ASLR rollout

was therefore not "full", because it ignored the a.out. Hence, the invention

of PIE. PIE are "executables" built as ET_DYN, which can be mapped arbitrarily.

With PIE, you can have "full ASLR"

Hence, for "full ASLR", you need -ztype=PIE, and if you define "full" as also meaning

"high quality", then you should also compile it as PIC.

I'm not really sure what -DPIC does, if anything, so I'll leave that to a compiler expert

to answer.

If you were running the latest development bits, as I am, you'd see a

different result:

    [email protected]% file /usr/bin/* | grep position | wc -l

    385

These things take time to work through the pipeline, but you will eventually  see

PIE in the system.

Ali Bahrami-Oracle

The short answer is: Yes, you do.

As you undoubtedly know, ASLR works by altering the mapped addresses of

mapped objects.

ASLR has always been able to work on the shared objects in a process, because

shared objects are ET_DYN, built to be mapped at arbitrary addresses. Shared

objects should always be built PIC, because otherwise, they end up containing code

that needs to be fixed up at load time, imposing unnecessary startup costs.

ASLR has traditionally not able to work on the main "a.out" object, because such

objects were built as ET_EXEC, fixed to a known address.  The initial ASLR rollout

was therefore not "full", because it ignored the a.out. Hence, the invention

of PIE. PIE are "executables" built as ET_DYN, which can be mapped arbitrarily.

With PIE, you can have "full ASLR"

Hence, for "full ASLR", you need -ztype=PIE, and if you define "full" as also meaning

"high quality", then you should also compile it as PIC.

I'm not really sure what -DPIC does, if anything, so I'll leave that to a compiler expert

to answer.

If you were running the latest development bits, as I am, you'd see a

different result:

    [email protected]% file /usr/bin/* | grep position | wc -l

    385

These things take time to work through the pipeline, but you will eventually  see

PIE in the system.

Steve.Clamage-Oracle

-DPIC is not needed by Studio compilers or by Solaris. An application might use a macro PIC for its own purposes.

Steve.Clamage-Oracle

On the current Solaris 11.3 bits, you can run

$ elfdump -d /usr/bin/* /usr/sbin/* 2>&1 | grep SUNW_ASLR | grep -c ENABLE

and see a large number of files that use ASLR. Shared libraries also use ASLR.

Alanc-Oracle

-DPIC does exactly what you'd expect, it #define's PIC, which is commonly used with inline assembly to choose between PIC & non-PIC versions, and because GNU autoconf defines it when building shared libraries, is sometimes used when code differs between shared & static libraries.  I'm not aware of anything in the core Solaris headers that checks for #ifdef PIC, but I wouldn't be surprised if some of our bundled FOSS libraries have such checks in headers your program may be including.