From: James Morse <james.morse@arm.com>
To: Peter Collingbourne <pcc@google.com>, Will Deacon <will@kernel.org>
Cc: libc-alpha@sourceware.org, Szabolcs Nagy <szabolcs.nagy@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Linux API <linux-api@vger.kernel.org>,
Kostya Serebryany <kcc@google.com>,
Florian Weimer <fw@deneb.enyo.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Andrey Konovalov <andreyknvl@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
Evgenii Stepanov <eugenis@google.com>
Subject: Re: [PATCH v6 3/3] arm64: pac: Optimize kernel entry/exit key installation code paths
Date: Fri, 12 Feb 2021 11:01:06 +0000 [thread overview]
Message-ID: <c314e144-26d7-d80c-ce83-5fd597a8f772@arm.com> (raw)
In-Reply-To: <CAMn1gO4OGsYYXBAWk=OiauZoyHoPFR9znSeLfXV0rLoZ+H7j1A@mail.gmail.com>
Hi Peter,
On 12/02/2021 05:01, Peter Collingbourne wrote:
> On Tue, Jan 26, 2021 at 5:09 AM Will Deacon <will@kernel.org> wrote:
>>
>> 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
> For GA I would expect it to be controlled by a hypothetical EnGA, not
> by EnIA (and I'm a bit surprised that there isn't an EnGA;
PACGA is undefined if the CPU doesn't implement PAC, whereas PACIASP is a NOP if the CPU
doesn't implement PAC.
I think the reason from the SCTLR_ELx controls is to make unaware systems transform the
instructions that were hints back into hints. (e.g. the AddPACIA psuedo code). This is
needed on mismatched big-little systems, otherwise processes can't be migrated between them.
For the non-hint instructions, user-space needs to test the hwcap/id-register-emulation to
know it can use these instructions, and the compiler shouldn't output them unconditionally.
> doesn't it
> mean that a userspace program running under an unaware kernel or
> hypervisor may sign things using the GA from potentially another
> hypervisor guest?)
The hypervisor controls all this with HCR_EL2.API, which also traps PACGA et al.
For the hypervisor its all or nothing.
If the hypervisor is emulating a machine without PAC, it can emulate an undefined
exception regardless of whether the CPU supports PAC or not.
Does this match your reading?
Thanks,
James
next prev parent reply other threads:[~2021-02-12 11:04 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
2021-02-12 5:01 ` Peter Collingbourne
2021-02-12 11:01 ` James Morse [this message]
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=c314e144-26d7-d80c-ce83-5fd597a8f772@arm.com \
--to=james.morse@arm.com \
--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 \
--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 NNTP newsgroup(s).