[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20120504011807.GV14673@brightrain.aerifal.cx>
Date: Thu, 3 May 2012 21:18:07 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: SSP and PIE support in musl
Hi all,
I've committed real SSP support (i.e. it really sets up a canary
rather than letting whatever data happens to be at a certain point in
the thread structure act as a canary) and PIE support in musl. The
overhead is zero for static linked programs that don't use it and
minimal (just some dead code) for the shared library if SSP is not in
use (no runtime size or performance cost).
These features should make musl a lot more appealing to
security-oriented distributions and applications and should not impact
users who are not using them.
Note that PIE requires the main executable to be fully PIC; textrels
are not supported. This means you cannot pull in any .a libs that were
not built with -fPIC and expect it to work; you have to use PIC .a
files or shared libraries. In theory, if all your .a files are built
PIC, you can have everything (including libc) static linked into the
PIE executable but it will still need ld-musl to relocate it at
runtime. If there's interest in support for textrels, I may add it,
but it would still not be possible on x86_64 (where the linker refuses
to even generate textrels).
It may also be possible (not sure yet) to generate fully static linked
PIE executables which do not require a dynamic linker at all (no
PT_INTERP header), by including a simplified version of the dynamic
linker (relative relocs only) in the main program binary (called from
the start code) and linking with -Bsymbolic. As far as I know, this
has never been done before, but it seems possible and definitely is
the sort of thing musl likes to tackle...
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
