From: Will Deacon <will@kernel.org>
To: Peter Collingbourne <pcc@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Evgenii Stepanov <eugenis@google.com>,
Kostya Serebryany <kcc@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
Szabolcs Nagy <szabolcs.nagy@arm.com>,
Florian Weimer <fw@deneb.enyo.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Andrey Konovalov <andreyknvl@google.com>,
linux-api@vger.kernel.org, libc-alpha@sourceware.org
Subject: Re: [PATCH v6 3/3] arm64: pac: Optimize kernel entry/exit key installation code paths
Date: Tue, 26 Jan 2021 13:09:48 +0000 [thread overview]
Message-ID: <20210126130947.GD29702@willie-the-truck> (raw)
In-Reply-To: <e3977b3e1b548be1d9554ccfad6c83ac87802583.1609311499.git.pcc@google.com>
On Tue, Dec 29, 2020 at 10:59:15PM -0800, Peter Collingbourne wrote:
> The kernel does not use any keys besides IA so we don't need to
> install IB/DA/DB/GA on kernel exit if we arrange to install them
> on task switch instead, which we can expect to happen an order of
> magnitude less often.
>
> Furthermore we can avoid installing the user IA in the case where the
> user task has IA disabled and just leave the kernel IA installed. This
> also lets us avoid needing to install IA on kernel entry.
I've got to be honest, this makes me nervous in case there is a way for
userspace to recover the kernel key even though EnIA is clear. Currently,
EnIA doesn't affect XPAC* and PACGA instructions, and the architecture
clearly expects us to be switching these things:
| Note
| Keys are not banked by Exception level. Arm expects software to switch the
| keys between Exception levels, typically by swapping the values with zero
| so that the current key values are not present in memo
But then:
> On an Apple M1 under a hypervisor, the overhead of kernel entry/exit
> has been measured to be reduced by 15.6ns in the case where IA is
> enabled, and 31.9ns in the case where IA is disabled.
That's a good improvement, so this feels like its worth doing. I suppose all we
can do is keep an eye on the architecture in case any future extensions mean
the approach taken here is dangerous.
Will
next prev parent reply other threads:[~2021-01-26 13:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-30 6:59 [PATCH v6 1/3] arm64: mte: make the per-task SCTLR_EL1 field usable elsewhere Peter Collingbourne
2020-12-30 6:59 ` [PATCH v6 2/3] arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS) Peter Collingbourne
2021-01-26 12:49 ` Will Deacon
2021-02-12 4:52 ` Peter Collingbourne
2020-12-30 6:59 ` [PATCH v6 3/3] arm64: pac: Optimize kernel entry/exit key installation code paths Peter Collingbourne
2021-01-26 13:09 ` Will Deacon [this message]
2021-02-12 5:01 ` Peter Collingbourne
2021-02-12 11:01 ` James Morse
2021-02-12 18:20 ` Peter Collingbourne
2021-01-26 12:49 ` [PATCH v6 1/3] arm64: mte: make the per-task SCTLR_EL1 field usable elsewhere Will Deacon
2021-02-12 4:47 ` 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=20210126130947.GD29702@willie-the-truck \
--to=will@kernel.org \
--cc=Dave.Martin@arm.com \
--cc=andreyknvl@google.com \
--cc=catalin.marinas@arm.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 \
/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