[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4c49c85a-2b2e-e408-534d-586f06a8e485@intel.com>
Date: Fri, 8 Sep 2023 08:14:41 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Robert Kueffner <r.m.kueffner@...il.com>
Cc: Kyle Huey <me@...ehuey.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: Memory protection keys: Signal handlers crash if pkey0 is
write-disabled
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.
Powered by blists - more mailing lists