[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Sep 2014 16:50:28 -0700
From: Andy Lutomirski <luto@...capital.net>
To: musl@...ts.openwall.com
Subject: Re: A running list of questions from "porting" Slackware to musl
On 09/30/2014 08:50 AM, Rich Felker wrote:
> On Tue, Sep 30, 2014 at 08:32:16AM -0700, Isaac Dunham wrote:
>> On Tue, Sep 30, 2014 at 06:13:37PM +0530, Weldon Goree wrote:
>>> Hi all,
>>>
>>> I added the quotation marks of shame because it's not a "port" in a real
>>> sense. But still: I've had this side project[1] for a while of porting
>>> Slackware to use Musl and it's Nearly There (tm), but I was hoping for some
>>> advice on some persistent irritations I have. (Sorry for the length.)
>> <snip>
>>> 6. Stack protection. This one really puzzles me. Stack protection is as
>>> alien to glibc as it is to musl, but I keep running into this. 90% of the
>>> problems can be avoided with adding -fno-stack-protector appropriately, but
>>> libtool is very "helpful" on matters like this and seems to find a way to
>>> put it back. I've actually not found an unworkable problem yet (though
>>> several very annoying ones); I guess I'm just curious what the real state of
>>> ssp on musl is (I'm not a fan of the concept, personally, but I know a lot
>>> of people are), and whether there's a general solution to just telling
>>> software to trust the ****ing stack.
>>
>> You need a "libssp_nonshared.a" containing a function named
>> __stack_chk_fail_local, which need only call __stack_chk_fail.
>> No idea why, but this cannot be in a shared libary.
>
> When gcc generates the canary-check code, on failure it normally
> calls/jumps to __stack_chk_fail. But for shared libraries, that call
> would go to a thunk in the library's PLT, which depends on the GOT
> register being initialized (actually this varies by arch; x86_64
> doesn't need it). In order to avoid (expensive) loading of the GOT
> register in every function just as a contingency in case
> __stack_chk_fail needs to be called, for position-independent code GCC
> generates a call to __stack_chk_fail_local instead. This is a hidden
> function (and necessarily exists within the same .so) so the call
> doesn't have to go through the PLT; it's just a straight relative
> call/jump instruction. __stack_chk_fail_local is then responsible for
> loading the GOT register and calling __stack_chk_fail.
[slightly off topic]
Does GCC even know how to call through the GOT instead of the PLT?
Windows (at least 32-bit Windows) has done for decades, at least if
dllimport is set.
On x86_64, this would be call *whatever@...off(%rip) instead of call
whatever@....
(Even better: the loader could patch the PLT with a direct jump. Could
musl do this? At least in the case where the symbol is within 2G of the
PLT entry, this should be straightforward if no threads have been
started yet. If musl did this, it could advertise a nice speedup over
glibc...)
--Andy
>
> 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.
