From: Mark Rutland <mark.rutland@arm.com>
To: Derrick McKee <derrick.mckee@gmail.com>
Cc: Yianni Giannaris <yiannig@mit.edu>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
suzuki.poulose@arm.com, Catalin Marinas <catalin.marinas@arm.com>,
james.morse@arm.com, amit.kachhap@arm.com, will@kernel.org
Subject: Re: PAC key changes when kernel code is preempted
Date: Fri, 30 Apr 2021 16:04:38 +0100 [thread overview]
Message-ID: <20210430150438.GA57205@C02TD0UTHF1T.local> (raw)
In-Reply-To: <CAJoBWHxHqUY427-62=YtGDtnGrcSyOXiKTF=A+Vswbt0K_7c+w@mail.gmail.com>
On Fri, Apr 30, 2021 at 10:40:04AM -0400, Derrick McKee wrote:
> Hi,
>
> I am noticing that when kernel code is preempted, PAC keys seem to
> change when resuming execution. For instance, when I read
> APDAKeyHi_EL1 and APDAKeyLo_EL1, sleep, and read them again, the
> values are different. Is this the intended behavior?
This is expected; kernel-side we only use the IA keys (which should stay
the same from a kernel task's PoV), and the other keys (IB, DA, DB, GA)
are not supposed to be used within the kernel.
Up to and including v5.12, the other keys are switched at entry to/from
userspace, and so may change from the PoV of a kernel thread across
preemption.
With the patches merged for v5.13, the other keys will be
switched with the task, but userspace can reset these at any time, and
they are still not supposed to be used within the kernel.
> If so, how can I ensure that the keys do not change? The different
> keys are causing PAC authentication to fail on pointers signed using
> the stale key. Thanks.
I take it this is non-mainline code? We shouldn't be using the other
keys today.
If you want to use the other keys, you'll need to alter the
context-switch and userspace entry/exit logic to have kernel versions of
the other keys, and switch them at the same points we switch the IA
keys.
For reference, see commit:
b90e483938ce387c ("arm64: pac: Optimize kernel entry/exit key installation code paths")
Thank,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-04-30 15:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-30 14:40 PAC key changes when kernel code is preempted Derrick McKee
2021-04-30 15:04 ` Mark Rutland [this message]
2021-05-07 20:24 ` Derrick McKee
2021-05-20 15:18 ` [PATCH] Ensure kernel AI key is not changed on fork Derrick McKee
2021-05-20 16:00 ` Mark Rutland
2021-05-20 18:24 ` Derrick McKee
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=20210430150438.GA57205@C02TD0UTHF1T.local \
--to=mark.rutland@arm.com \
--cc=amit.kachhap@arm.com \
--cc=catalin.marinas@arm.com \
--cc=derrick.mckee@gmail.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yiannig@mit.edu \
/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