On 9/7/23 16:07, Robert Kueffner wrote: >> 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. Well, the "pushes the processor state onto the stack" part is probably the problem. That processor state _includes_ PKRU and it's also eventually the only place that processor state exists. That means that there's no simple solution. You can't just move up where PKRU gets reset because that will blow away the PKRU that you need to save on the stack. There are tons of complicated ways to fix this. But the easiest way is just to say that you need to keep PKRU set so that the signal frame can be written at any time.
