prelink/ExecShield/PIE interactions?

[Roland McGrath]

> But if that's the case, then what exactly does the --no-exec-shield
> option to prelink actually *do*?  What functionality of ExecShield
> (that it doesn't already conflict with) is left for it to disable?

This option affects how prelink chooses the addresses to place libraries
at.  The default is --exec-shield when the kernel has exec-shield enabled
at the time prelink is run, and --no-exec-shield if not.  Under
--no-exec-shield, it uses the traditional mmap region starting at
0x41000000, which is out of the way of things that want to use fixed
addresses below there.  Under --exec-shield, prelink uses addresses
optimized to interact well with addresses that exec-shield randomization
chooses, which may conflict with old assumptions about where "anywhere"
mappings wind up.

> The nonselsec.pdf document also states that PIEs are excluded from
> prelinking.  That makes sense.  But if code segments aren't writable
> (and I don't believe they are, IIRC), what benefit does PIE actually
> bring?  Is it trying to make it harder for an attacker to leverage
> pre-existing code in the application to launch an exploit?

Yes, that is the point.  Many exploits work by jumping to known addresses
in the commonly-found binary of the program being attacked.  With PIE,
these addresses are not constant any more.  It is the same issue as
exec-shield randomization of mmap locations addresses for dynamically
allocated data (or executable code) pages.