mprotect PROT_SIGNAL

mprotect PROT_SIGNAL

[Soni "They/Them" L.]

we'd like an mprotect PROT_SIGNAL flag for a compiler we're making

PROT_SIGNAL - marks the pages as unmapped while running signal handlers

this would be very useful, do you think you could provide it?

(not much more to say about it, it's supposed to do what it says on the 
tin, we want to unmap pages in signal handlers so as to catch bugs 
without causing memory corruption.)

Re: mprotect PROT_SIGNAL

[Florian Weimer]

* Soni L.:

> we'd like an mprotect PROT_SIGNAL flag for a compiler we're making
>
> PROT_SIGNAL - marks the pages as unmapped while running signal handlers
>
> this would be very useful, do you think you could provide it?
>
> (not much more to say about it, it's supposed to do what it says on
> the tin, we want to unmap pages in signal handlers so as to catch bugs
> without causing memory corruption.)

The challenge is going to be to detect abnormal exit from the signal
handler.

You can already get some of this behavior to today with memory
protection keys, on x86-64 at least.  (I consider this a glitch in the
implementation, it makes it less useful.)  Access is revoked
automatically when the hander is invoked.  However, access is not
restored if you jump out of the handler using longjmp or by throwing an
exception.

Thanks,
Florian

Re: mprotect PROT_SIGNAL

[Soni "They/Them" L.]

On 2024-07-16 12:13, Florian Weimer wrote:
> * Soni L.:
>
> > we'd like an mprotect PROT_SIGNAL flag for a compiler we're making
> >
> > PROT_SIGNAL - marks the pages as unmapped while running signal handlers
> >
> > this would be very useful, do you think you could provide it?
> >
> > (not much more to say about it, it's supposed to do what it says on
> > the tin, we want to unmap pages in signal handlers so as to catch bugs
> > without causing memory corruption.)
>
> The challenge is going to be to detect abnormal exit from the signal
> handler.
>
> You can already get some of this behavior to today with memory
> protection keys, on x86-64 at least.  (I consider this a glitch in the
> implementation, it makes it less useful.)  Access is revoked
> automatically when the hander is invoked.  However, access is not
> restored if you jump out of the handler using longjmp or by throwing an
> exception.

As it should be - POSIX specifies that longjmping out of a handler 
remains in handler context, so you still can't call signal-unsafe functions.

Presumably, an API to manually map them back in would be necessary in 
the case of e.g. the JVM, which uses signal handlers for 
hardware-accelerated null checks.

> Thanks,
> Florian
>