linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Derrick McKee <derrick.mckee@gmail.com>
To: Mark Rutland <mark.rutland@arm.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, 7 May 2021 16:24:57 -0400	[thread overview]
Message-ID: <CAJoBWHwZBEAGmCAeaBNUx2FxQh2oUWSH8HbxgNsxnzwrBuMGzQ@mail.gmail.com> (raw)
In-Reply-To: <20210430150438.GA57205@C02TD0UTHF1T.local>

On Fri, Apr 30, 2021 at 11:04 AM Mark Rutland <mark.rutland@arm.com> wrote:
>
> 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.

Thanks for the response.  When was the preservation and restoration of
the IA key added to the kernel, because in my 5.10 code base, I am
seeing the IA key change for the kernel between system calls.

> 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.

Yeah, I'm a doctorate researcher attempting to combine PAC and MTE to
harden kernel modules, which is why I am trying to make sure PAC keys
are the same. Pointers to kernel data are being signed and
authenticated using different keys.  It actually doesn't matter for
our purposes what key is used, just that the key remains the same
whenever kernel code gets executed.

Thanks.
--
Derrick McKee

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-07 20:26 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
2021-05-07 20:24   ` Derrick McKee [this message]
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=CAJoBWHwZBEAGmCAeaBNUx2FxQh2oUWSH8HbxgNsxnzwrBuMGzQ@mail.gmail.com \
    --to=derrick.mckee@gmail.com \
    --cc=amit.kachhap@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --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;
as well as URLs for NNTP newsgroup(s).