This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SafeStack proposal in GCC




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]