From: Dave Hansen <dave.hansen@intel.com>
To: Robert Kueffner <r.m.kueffner@gmail.com>
Cc: Kyle Huey <me@kylehuey.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Memory protection keys: Signal handlers crash if pkey0 is write-disabled
Date: Fri, 8 Sep 2023 08:14:41 -0700 [thread overview]
Message-ID: <4c49c85a-2b2e-e408-534d-586f06a8e485@intel.com> (raw)
In-Reply-To: <E821837A-22AD-420C-A290-8511344E7EAF@gmail.com>
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.
next prev parent reply other threads:[~2023-09-08 15:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-07 21:22 Memory protection keys: Signal handlers crash if pkey0 is write-disabled Robert Kueffner
2023-09-07 21:31 ` Dave Hansen
2023-09-07 23:07 ` Robert Kueffner
2023-09-08 15:14 ` Dave Hansen [this message]
2023-09-08 15:43 ` Robert Kueffner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4c49c85a-2b2e-e408-534d-586f06a8e485@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=me@kylehuey.com \
--cc=r.m.kueffner@gmail.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox