[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140627203609.GA16724@brightrain.aerifal.cx>
Date: Fri, 27 Jun 2014 16:36:09 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Re: getcontext etc was Re: Re: go support (was:
Best place to discuss other lightweight libraries?)
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.
> 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.
Also, it's possible that we could support kernel-provided and
userspace-generated contexts separately as long as there's space to
store which type a given context is.
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.
