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.