This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SafeStack proposal in GCC
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Michael Matz <matz at suse dot de>, Rich Felker <dalias at libc dot org>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 9 May 2016 15:07:57 -0500
- Subject: Re: SafeStack proposal in GCC
- Authentication-results: sourceware.org; auth=none
- 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>
On 5/9/2016 3:03 PM, Michael Matz wrote:
Hi,
On Mon, 9 May 2016, Rich Felker wrote:
The *context APIs are deprecated and I'm not sure they're worth
supporting with this. It would be a good excuse to get people to
stop using them.
How? POSIX decided to remove the facilities without any adequate
replacement (thread aren't).
Threads work just as well as the ucontext api for coroutines. Due to the
requirement to save/restore signal masks, the latter requires a syscall,
making it no faster than a voluntary context switch via futex syscall.
Uhm, no. If you disregard efficiency, sure, POSIX threads are sometimes a
replacement on some platforms. They still have completely different
activation models (being synchronous with *context, for which you need
even further slow synchronization in a threading model).
One complication on RTEMS which is a single process, multi-threaded RTOS
is that we can no longer check the stack bounds. For threads, we know
where the stack memory is and the range for each thread. For ucontext_t,
it seems this knowledge is unknown to the RTOS.
Thus it would become the responsibility of the run-time using ucontext_t
to put in fence patterns and check those.
Most of the other hacks people used the ucontext API for were complete
hacks with undefined behavior, anyway.
Sure, that doesn't imply the facility should be removed. I can misuse all
kinds of stuff.
BTW it's not even possible to implement makecontext on most targets due
to the wacky variadic calling convention it uses -- in most ABIs,
there's simply no way to shift the variadic args into the right slots
for calling the start function for the new context without knowing their
types, and the implementation has no way to know the types. So it's
really an unusably broken API.
Of course. But _that_ implies that a workable replacement should have
been put in place, not the unrealistic stance POSIX took with the removal:
makecontext2(ucontext_t *ucp, void (*func)(void*), void* cookie);
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).
Ciao,
Michael.
--joel