[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <53B1ADCA.60604@mit.edu>
Date: Mon, 30 Jun 2014 11:34:50 -0700
From: Andy Lutomirski <luto@...capital.net>
To: musl@...ts.openwall.com
Subject: Re: getcontext etc was Re: Re: go support (was: Best place
to discuss other lightweight libraries?)
On 06/27/2014 01:36 PM, Rich Felker wrote:
> On Fri, Jun 27, 2014 at 12:41:11PM -0700, Andy Lutomirski wrote:
>> On 06/23/2014 03:32 PM, Rich Felker wrote:
>>> On Mon, Jun 23, 2014 at 10:09:29PM +0100, Justin Cormack wrote:
>>>> On Wed, Apr 24, 2013 at 2:42 PM, Rich Felker <dalias@...ifal.cx> wrote:
>>>>>> i tried to build gcc 4.7.2 with go support (--enable-languages=c,c++,go)
>>>>>> and that fails due to a lack of set/getcontext().
>>>>>> (see pkg/gcc472 in sabotage)
>>>>>>
>>>>>> according to rich, adding that to musl requires a non-trivial amount
>>>>>> of arch specific asm.
>>>>>
>>>>> Yes, but it is a wanted feature, so I wouldn't mind it getting done.
>>>>> It was even part of the standard prior to POSIX 2008, and the reason
>>>>> for removing it was stupid. (The reason was that the makecontext
>>>>> function's calling convention is bogus and impossible to support
>>>>> properly, but they could have fixed this by deprecating the use of the
>>>>> variadic arguments in any way except passing a single void* argument,
>>>>> rather than deprecating the whole set of interfaces.)
>>>>
>>>> Just to revive this post 1.0, it would be very nice indeed to have
>>>> set,get,swapcontext.
>>>
>>> One approach to setcontext would be using rt_sigreturn, but I've heard
>>> there are issues using it for setcontext involving the alternate
>>> signal stack. It's the only way to do resuming _async_ (i.e. the
>>> ucontext received by a signal handler for the state it interrupted)
>>> contexts though, so maybe there's some way to make it work. This issue
>>> was discussed recently on libc-alpha (the glibc list).
>>
>> What's the async issue?
>
> It's impossible to do setcontext to an async context (given to you via
> the kernel as the ucontext_t argument to a signal handler) without
> rt_sigreturn since the context may store cpu-model-specific
> information in the context beyond what userspace is aware of. For
> example, if libc is only built for the baseline ISA but the
> application is using some SIMD extensions, the kernel may save the
> SIMD state at the end of the context in some form that's not a public
> API, and libc has no way to restore that.
Right.
>
>> I think that using rt_sigreturn for this directly (rather than sending
>> yourself a signal, adjusting the context, and returning) is a bad idea:
>> there are patches floating around to mitigate SROP (sigreturn-oriented
>> programming) by adding signal frame canaries, and you'll go boom if that
>> happens.
>
> Can your provide me with links to threads on the topic? Depending on
> how they work, there's a small chance they could break cancellation
> behavior on musl (and make it impossible to do safe cancellation), and
> if so I want to make sure that issue is raised and fixed before the
> problem gets integrated anywhere. If it's just a canary it's no
> problem, but if they did some kind of checksum of the context, that
> would be a big problem.
http://lkml.kernel.org/g/20140515210914.GA9536@pizzadoos.com
I haven't spotted any more on the subject, though.
--Andy
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.
