From: Catalin Marinas <catalin.marinas@arm.com>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>
Cc: Peter Collingbourne <pcc@google.com>,
Florian Weimer <fw@deneb.enyo.de>,
libc-alpha@sourceware.org, Kevin Brodsky <kevin.brodsky@arm.com>,
Linux API <linux-api@vger.kernel.org>,
Kostya Serebryany <kcc@google.com>,
Evgenii Stepanov <eugenis@google.com>,
Andrey Konovalov <andreyknvl@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Will Deacon <will@kernel.org>, Dave Martin <Dave.Martin@arm.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS)
Date: Wed, 18 Nov 2020 12:33:36 +0000 [thread overview]
Message-ID: <X7UUoFcmtuHEhoz9@trantor> (raw)
In-Reply-To: <20201117183911.GI15033@arm.com>
On Tue, Nov 17, 2020 at 06:39:13PM +0000, Szabolcs Nagy wrote:
> The 11/17/2020 10:17, Peter Collingbourne via Libc-alpha wrote:
> > On Tue, Nov 17, 2020 at 9:48 AM Florian Weimer <fw@deneb.enyo.de> wrote:
> > >
> > > * Peter Collingbourne:
> > >
> > > > This prctl allows the user program to control which PAC keys are enabled
> > > > in a particular task. The main reason why this is useful is to enable a
> > > > userspace ABI that uses PAC to sign and authenticate function pointers
> > > > and other pointers exposed outside of the function, while still allowing
> > > > binaries conforming to the ABI to interoperate with legacy binaries that
> > > > do not sign or authenticate pointers.
> > > >
> > > > The idea is that a dynamic loader or early startup code would issue
> > > > this prctl very early after establishing that a process may load legacy
> > > > binaries, but before executing any PAC instructions.
> > >
> > > I thought that the silicon did not support this?
I think the past discussion we had was around enabling PAC for kernel
while disabling it for user. The hardware doesn't give us separate bits,
so Peter's patch toggles them on kernel entry/return, with some overhead
given by the MSR+ISB (to be added).
> > See e.g. the documentation for SCTLR_EL1.EnIA [1] for details. There
> > are also enable bits for the other three keys.
>
> i think it was insufficiently clear in the architecture
> spec how that can be context switched. (but it probably
> changed)
The bits that we can't toggle easily have the comment "This field is
permitted to be cached in the TLB" in the ARM ARM. Luckily, it's not the
case for EnI*.
--
Catalin
next prev parent reply other threads:[~2020-11-18 12:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20201014055106.25164-1-pcc@google.com>
2020-11-17 17:29 ` Catalin Marinas
2020-11-17 18:14 ` Szabolcs Nagy
2020-11-17 18:40 ` Peter Collingbourne
2020-11-17 17:48 ` Florian Weimer
2020-11-17 18:17 ` Peter Collingbourne
2020-11-17 18:39 ` Szabolcs Nagy
2020-11-18 12:33 ` Catalin Marinas [this message]
2020-11-18 13:31 ` Szabolcs Nagy
2020-11-18 13:37 ` Catalin Marinas
2020-11-18 17:19 ` Dave Martin
2020-11-18 17:31 ` Florian Weimer
2020-11-18 18:18 ` Dave Martin
2020-11-18 12:25 ` Catalin Marinas
2020-11-19 5:20 ` Peter Collingbourne
2020-11-18 17:55 ` Dave Martin
2020-11-18 19:05 ` Peter Collingbourne
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=X7UUoFcmtuHEhoz9@trantor \
--to=catalin.marinas@arm.com \
--cc=Dave.Martin@arm.com \
--cc=andreyknvl@google.com \
--cc=eugenis@google.com \
--cc=fw@deneb.enyo.de \
--cc=kcc@google.com \
--cc=kevin.brodsky@arm.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=pcc@google.com \
--cc=szabolcs.nagy@arm.com \
--cc=vincenzo.frascino@arm.com \
--cc=will@kernel.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).