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
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org> To: Peter Collingbourne <pcc@google.com> 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@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: 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 _______________________________________________ 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-01-26 13:11 UTC|newest] Thread overview: 22+ 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 ` Peter Collingbourne 2020-12-30 6:59 ` [PATCH v6 2/3] arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS) Peter Collingbourne 2020-12-30 6:59 ` Peter Collingbourne 2021-01-26 12:49 ` Will Deacon 2021-01-26 12:49 ` Will Deacon 2021-02-12 4:52 ` Peter Collingbourne 2021-02-12 4:52 ` [PATCH v6 2/3] arm64: Introduce prctl(PR_PAC_{SET, GET}_ENABLED_KEYS) Peter Collingbourne 2020-12-30 6:59 ` [PATCH v6 3/3] arm64: pac: Optimize kernel entry/exit key installation code paths Peter Collingbourne 2020-12-30 6:59 ` Peter Collingbourne 2021-01-26 13:09 ` Will Deacon [this message] 2021-01-26 13:09 ` Will Deacon 2021-02-12 5:01 ` Peter Collingbourne 2021-02-12 5:01 ` Peter Collingbourne 2021-02-12 11:01 ` James Morse 2021-02-12 11:01 ` James Morse 2021-02-12 18:20 ` Peter Collingbourne 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-01-26 12:49 ` Will Deacon 2021-02-12 4:47 ` Peter Collingbourne 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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.