This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SafeStack proposal in GCC
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Michael Matz <matz at suse dot de>, Rich Felker <dalias at libc dot org>
- Cc: <nd at arm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 10 May 2016 11:15:46 +0100
- Subject: Re: SafeStack proposal in GCC
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <CAFA9rWPkb=eV0GhvFeOnd4pRVh=N3fSifYBwZjy9Ndh68BmBww at mail dot gmail dot com> <0d50f0ef01b24c25a79a6f18eaddfd6d at REXA dot intranet dot epfl dot ch> <CANL6WeqEwFYx2H-sv81K8CDFypiJ+ray+xPyRH+7kitTpD8bqw at mail dot gmail dot com> <20160507054212 dot GE21636 at brightrain dot aerifal dot cx> <alpine dot LSU dot 2 dot 20 dot 1605092101000 dot 13156 at wotan dot suse dot de> <20160509193503 dot GF21636 at brightrain dot aerifal dot cx> <alpine dot LSU dot 2 dot 20 dot 1605092147020 dot 13156 at wotan dot suse dot de> <20160509204352 dot GG21636 at brightrain dot aerifal dot cx> <alpine dot LSU dot 2 dot 20 dot 1605092321460 dot 13156 at wotan dot suse dot de>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 09/05/16 22:45, Michael Matz wrote:
> On Mon, 9 May 2016, Rich Felker wrote:
>
>>> Done. I never understood why they left in the hugely unuseful
>>> {sig,}{set,long}jmp() but removed the actually useful *context()
>>> (amended somehow like above).
>>
>> Because those are actually part of the C language
>
> Sure. Same QoI bug in my book. (And I'm not motivated enough to find out
> if the various C standards weren't just following POSIX whe setjmp was
> included, or really the other way around).
>
>> (the non-sig versions, but the sig versions are needed to work around
>> broken unices that made the non-sig versions save/restore signal mask
>> and thus too slow to ever use). They're also much more useful for
>> actually reasonable code (non-local exit across functions that were
>> badly designed with no error paths)
>
> Trivially obtainable with getcontext/setcontext as well.
>
>> as opposed to just nasty hacks that
>> are mostly/entirely UB anyway (coroutines, etc.).
>
> Well, we differ in the definition of reasonable :) And I certainly don't
> see any material difference in undefined behaviour between both classes of
> functions. Both are "special" regarding compilers (e.g. returning
> multiple times) and usage. But as the *jmp() functions can be implemented
> with *context(), but not the other way around, it automatically follows
no, no, no,
don't try to present getcontext as equal to setjmp,
getcontext is broken while setjmp is just ugly.
setjmp is defined so that the compiler can treat it
specially and the caller has to make sure certain
objects are volatile, cannot appear in arbitrary
places (e.g. in the declaration of a vla), longjmp
must be in same thread etc.
all those requirements that make setjmp implementible
at all were missing from the getcontext specs, so you
can call it through a function pointer and access
non-volatile modified local state after the second
return, etc. (the compiler treating "getcontext"
specially is a hack, not justified by any standard.)
i think both gccgo and qemu can setcontext into another
thread, so when getcontext returns all tls object
addresses are wrong.. the semantics of this case was
not properly defined anywhere (and there are
implementation internal objects with thread local
storage duration like fenv so this matters even if
the caller does not use tls). this is unlikely to
work correctly with whatever safestack implementation.
setcontext were originally specified to be able to
use the ucontext from async signal handlers.. this
turned out to be problematic for several reasons
(kernel saved ucontext is different from user space
ucontext and sigaltstack needs special treatment).
if setcontext finishes executing the last linked
context in the main thread it was not clearly
specified what cleanups will be performed.
there is just a never ending list of issues with
these apis, so unless there is an actual proposal
how to tighten their specification, any caller of
the context apis rely on undefined semantics.
> (to me!) that the latter are more useful, if for nothing else than basic
> building blocks. (there are coroutine libs that try to emulate a real
> makecontext with setjmp/longjmp on incapable architectures. As this is
> impossible for all corner cases they are broken and generally awful on
> them :) )
>
>
> Ciao,
> Michael.
>