Re: fixing -fPIE + -fstack-protector-all

[Rich Felker <dalias@libc.org>]

On Wed, Nov 05, 2014 at 05:01:31PM +0100, John Spencer wrote:
> Rich Felker wrote:
> >On Wed, Nov 05, 2014 at 04:25:03PM +0100, John Spencer wrote:
> >>using -fPIE + -fstack-protector-all is currently broken for a number
> >>of architectures (most notably i386) in the default gcc setup
> >>(including the musl-cross patches), as it depends on a
> >>libssp_nonshared.a which provides __stack_chk_fail_local().
> >
> >As discussed on IRC, I would _like_ to be able to simply add the
> >following to crt/i386/crti.s:
> >
> >__stack_chk_fail_local: hlt
> >
> >and equivalent for other archs. This has the added benefit of
> >effecting a crash without going through the PLT (whereas
> >libssp_nonshared.a's __stack_chk_fail_local calls __stack_chk_fail via
> >the PLT) so it's not vulnerable to attacks that have overwritten the
> >GOT with malicious pointers.
> >
> >However, this proposed solution breaks one odd corner case: static
> >linking when all the source files were compiled with -fPIC or -fPIE.
> >In that case, there would be no references to __stack_chk_fail, only
> >to __stack_chk_fail_local, and thereby __init_ssp would not get
> >linked, and a zero canary would be used.
> >
> >One possible way to handle this would be giving up the conditional
> >linking of ssp init and just always initializing it. The .o file is 78
> >bytes on i386 and 70 bytes on x86_64, but there would also be some
> >savings to offset the cost simply from having the code inline in
> >__init_libc rather than as an external function.
> 
> that sounds reasonable. do you intend add this symbol and the
> mandatory init_ssp code even to archs that don't need it (for
> example x86_64) ?

Right now I don't have a specific "intent" since this is just an idea.
But I think it would probably be ugly, and preclude the inlining, to
do the __init_ssp stuff differently on different archs. The local
symbol could of course be omitted on archs that don't use it, but it
doesn't hurt to have it either.

Rich