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 13:37:47 +0000 [thread overview] Message-ID: <X7Ujq6RCzEQKFVId@trantor> (raw) In-Reply-To: <20201118133121.GA20578@arm.com> On Wed, Nov 18, 2020 at 01:31:21PM +0000, Szabolcs Nagy wrote: > The 11/18/2020 12:33, Catalin Marinas wrote: > > 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). > > ah ok. i probably incorrectly thought that toggling that sys > register bit is too much overhead at kernel entry so assumed > we cannot have PAC off by default or set per process. I think Peter can rerun his benchmarks but with the ISB added after MSR. If they are not too bad, we can take this series. > (i think with the proposed prctl it's possible to disable PAC > at early ld.so startup and reenable it before calling into the > main exe entry code, if we ever need to disable PAC-RET.) > > i assume thread creation/fork inherits the setting but exec > does not (this is another point that may be worth adding to > the documentation). Yes, that's my understanding from the patch. It should be documented explicitly (I haven't read the doc updates, maybe it does this already). > if we run into issues in userspace with PAC then a prctl that > can be inherited across exec is a possible workaround (so PAC > can be disabled for an entire process tree). Can you do something similar to MTE with an environment variable forcing PAC off? -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com> To: Szabolcs Nagy <szabolcs.nagy@arm.com> Cc: libc-alpha@sourceware.org, Will Deacon <will@kernel.org>, Linux API <linux-api@vger.kernel.org>, Kevin Brodsky <kevin.brodsky@arm.com>, 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>, Peter Collingbourne <pcc@google.com>, Dave Martin <Dave.Martin@arm.com>, Evgenii Stepanov <eugenis@google.com> Subject: Re: [PATCH v2] arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS) Date: Wed, 18 Nov 2020 13:37:47 +0000 [thread overview] Message-ID: <X7Ujq6RCzEQKFVId@trantor> (raw) In-Reply-To: <20201118133121.GA20578@arm.com> On Wed, Nov 18, 2020 at 01:31:21PM +0000, Szabolcs Nagy wrote: > The 11/18/2020 12:33, Catalin Marinas wrote: > > 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). > > ah ok. i probably incorrectly thought that toggling that sys > register bit is too much overhead at kernel entry so assumed > we cannot have PAC off by default or set per process. I think Peter can rerun his benchmarks but with the ISB added after MSR. If they are not too bad, we can take this series. > (i think with the proposed prctl it's possible to disable PAC > at early ld.so startup and reenable it before calling into the > main exe entry code, if we ever need to disable PAC-RET.) > > i assume thread creation/fork inherits the setting but exec > does not (this is another point that may be worth adding to > the documentation). Yes, that's my understanding from the patch. It should be documented explicitly (I haven't read the doc updates, maybe it does this already). > if we run into issues in userspace with PAC then a prctl that > can be inherited across exec is a possible workaround (so PAC > can be disabled for an entire process tree). Can you do something similar to MTE with an environment variable forcing PAC off? -- Catalin _______________________________________________ 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:[~2020-11-18 13:38 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-14 5:51 [PATCH v2] arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS) Peter Collingbourne 2020-10-14 5:51 ` Peter Collingbourne 2020-11-17 17:29 ` Catalin Marinas 2020-11-17 17:29 ` Catalin Marinas 2020-11-17 18:14 ` Szabolcs Nagy 2020-11-17 18:14 ` Szabolcs Nagy 2020-11-17 18:40 ` Peter Collingbourne 2020-11-17 18:40 ` Peter Collingbourne 2020-11-17 17:48 ` Florian Weimer 2020-11-17 17:48 ` Florian Weimer 2020-11-17 18:17 ` Peter Collingbourne 2020-11-17 18:17 ` Peter Collingbourne 2020-11-17 18:39 ` Szabolcs Nagy 2020-11-17 18:39 ` Szabolcs Nagy 2020-11-18 12:33 ` Catalin Marinas 2020-11-18 12:33 ` Catalin Marinas 2020-11-18 13:31 ` Szabolcs Nagy 2020-11-18 13:31 ` Szabolcs Nagy 2020-11-18 13:37 ` Catalin Marinas [this message] 2020-11-18 13:37 ` Catalin Marinas 2020-11-18 17:19 ` Dave Martin 2020-11-18 17:19 ` Dave Martin 2020-11-18 17:31 ` Florian Weimer 2020-11-18 17:31 ` Florian Weimer 2020-11-18 18:18 ` Dave Martin 2020-11-18 18:18 ` Dave Martin 2020-11-18 12:25 ` Catalin Marinas 2020-11-18 12:25 ` Catalin Marinas 2020-11-19 5:20 ` Peter Collingbourne 2020-11-19 5:20 ` Peter Collingbourne 2020-11-18 17:55 ` Dave Martin 2020-11-18 17:55 ` Dave Martin 2020-11-18 19:05 ` Peter Collingbourne 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=X7Ujq6RCzEQKFVId@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: 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.