Re: Memory protection keys: Signal handlers crash if pkey0 is write-disabled

[Robert Kueffner]

> I assume that *something* is trying to access pkey-0-protected memory.
> Any idea what that is?  Which entity is doing that access and what are
> they accessing?  The page fault tracepoints might come in handy.

If I understand correctly, the kernel (a) pushes the processor state onto the stack and (b) resets PKRU=0x55555554 some time before switching to the signal handler. And may try between (a) and (b) to write pkey-0-protected memory. 

This would be compatible with what I see when my user code causes a FPE, upon which there is a SEGV before the kernel switches to my signal handler. 

If the user code causes SEGV my signal handler actually executes and only fails later when returning from syscall 14 in sigprocmask(), i.e. sigprocmask() => __GI___sigprocmask => __GI___pthread_sigmask => syscall 14

I will look into tracepoints - but that would be diagnostic rather

As a farfetched solution, would there be a way, perhaps via a kernel hook, to reset PKRU before the kernel actually starts processing the signal?