[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120424221040.GS14673@brightrain.aerifal.cx>
Date: Tue, 24 Apr 2012 18:10:40 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: New gcc wrapper to try
On Tue, Apr 24, 2012 at 05:41:27PM -0400, Rich Felker wrote:
> On Wed, Apr 25, 2012 at 01:28:40AM +0400, Solar Designer wrote:
> > Rich, Isaac -
> >
> > On Tue, Apr 24, 2012 at 12:28:28PM -0700, Isaac Dunham wrote:
> > > On Mon, 23 Apr 2012 05:19:05 -0400 Rich Felker <dalias@...ifal.cx> wrote:
> > > > Somebody has enabled stack protector. Either your distro (what distro
> > > > are you using) has hacked gcc in a way different from what musl-gcc
> > > > expects, or wireless-tools' makefile is adding -fstack-protector...
> > >
> > > There's no -fstack-protector, so it's Ubuntu's fault.
> >
> > Several distros do it these days (and Owl will start doing it soon as
> > well), so it's becoming standard and needs to be supported.
> > Technically, -fno-stack-protector in the musl-gcc wrapper would probably
> > make things appear to work, but it's not necessarily a good thing to do
> > since it might violate reasonable expectations of the user. I think
> > it'd be better for musl to start providing the necessary symbols.
>
> The problem is that the default gcc build incorporates glibc ABI
> knowledge (layout of the thread structure) and the assumption that the
> thread pointer has been initialized into any binary built with stack
> protector. Just adding symbols will not fix anything.
>
> If gcc's stack protector support is built without TLS support so that
> it uses a global variable for the canary, instead of a thread-local
> variable, then we could support it with no work at all. Unfortunately
> I don't believe there's any way to override the type of canary access
> gcc does via command line options; you have to rebuild gcc. Thus, for
> the time being (until/unless we do TLS and mimic glibc's structure
> layout), disabling stack protector is the only option for the wrapper
> to use. For our own native gcc builds, we can already support it if I
> just add the symbol it needs.
......but since you requested it, I'm working on trying to make it
work anyway. We'll see how it goes. Preliminary support was just
committed.
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.
