[PATCH] arm64: Introduce sysctl to disable pointer authentication

[PATCH] arm64: Introduce sysctl to disable pointer authentication

[Steve Capper]

Pointer authentication is a mandatory feature in the Armv8.3
architecture that provides protection against return oriented
programming attacks. (meaning that all Arm CPUs targetting at least
Armv8.3 will have this feature).

Once CONFIG_ARM64_PTR_AUTH=y, any systems with the hardware support for
pointer authentication will automatically have it enabled by the kernel.

There are, however, situations where end users may want to disable
pointer authentication. One could be tracking down/working around a bug
in userspace relating to pointer auth. Also, one may wish to quantify
the performance overhead of pointer auth by running a workload
with/without it.

Linux distributions operate a single binary policy wherever possible,
meaning any mechanism to disable pointer authentication as a parameter
would be preferred greatly over building/supporting multiple kernels.

For hardware with pointer auth, this patch introduces the sysctl:
abi.ptrauth_disabled=1
which will disable pointer authentication for any new processes that are
exec'ed. (Reverting to 0 will then re-enable pointer authentication for
new processes).

One can set this sysctl on the kernel command line:
sysctl.abi.ptrauth_disabled=1
And this will ensure that pointer authentication is disabled for the init
process onwards.

Note that when pointer authentication is disabled by sysctl, the
capabilities are still exposed to userspace and pointer authentication
instructions can execute (it will just be as NOPs).

Signed-off-by: Steve Capper <steve.capper@arm.com>
---
 .../arm64/pointer-authentication.rst          | 32 ++++++++++++++++
 arch/arm64/include/asm/asm_pointer_auth.h     | 37 +++++++++++++++++++
 arch/arm64/include/asm/pointer_auth.h         | 10 +++--
 arch/arm64/include/asm/processor.h            |  1 +
 arch/arm64/kernel/asm-offsets.c               |  1 +
 arch/arm64/kernel/entry.S                     |  3 ++
 arch/arm64/kernel/process.c                   | 31 +++++++++++++++-
 7 files changed, 111 insertions(+), 4 deletions(-)

diff --git a/Documentation/arm64/pointer-authentication.rst b/Documentation/arm64/pointer-authentication.rst
index 30b2ab06526b..e8bc8336bbf2 100644
--- a/Documentation/arm64/pointer-authentication.rst
+++ b/Documentation/arm64/pointer-authentication.rst
@@ -107,3 +107,35 @@ filter out the Pointer Authentication system key registers from
 KVM_GET/SET_REG_* ioctls and mask those features from cpufeature ID
 register. Any attempt to use the Pointer Authentication instructions will
 result in an UNDEFINED exception being injected into the guest.
+
+
+Disabling Pointer Authentication
+--------------------------------
+There are situations where end users may want to disable pointer
+authentication. One could be tracking down/working around a bug in
+userspace relating to pointer authentication. Also, one may wish to
+quantify the performance overhead of pointer authentication by running a
+workload with/without it.
+
+For hardware with pointer auth, there is the following sysctl:
+
+.. code-block:: none
+
+        abi.ptrauth_disabled=1
+
+which will disable pointer authentication for any new processes that are
+exec'ed. (Reverting to 0 will then re-enable pointer authentication for
+any new processes).
+
+One can also set this sysctl on the kernel command line:
+
+.. code-block:: none
+
+        sysctl.abi.ptrauth_disabled=1
+
+And this will ensure that pointer authentication is disabled for the init
+process onwards.
+
+Note that when pointer authentication is disabled by sysctl, the
+capabilities are still exposed to userspace and pointer authentication
+instructions can execute (it will just be as NOPs).
diff --git a/arch/arm64/include/asm/asm_pointer_auth.h b/arch/arm64/include/asm/asm_pointer_auth.h
index 52dead2a8640..29fdd379bf1c 100644
--- a/arch/arm64/include/asm/asm_pointer_auth.h
+++ b/arch/arm64/include/asm/asm_pointer_auth.h
@@ -82,6 +82,38 @@ alternative_else_nop_endif
 .Lno_addr_auth\@:
 	.endm
 
+	.macro ptrauth_switch_to_user tsk, tmp1, tmp2, tmpw
+alternative_if_not ARM64_HAS_ADDRESS_AUTH
+	b	.Ldont_disable\@
+alternative_else_nop_endif
+	mov	\tmp2, #THREAD_PTRAUTH_DISABLED
+	ldr	\tmpw, [\tsk, \tmp2]
+	cbz	\tmpw, .Ldont_disable\@
+	mrs	\tmp1, sctlr_el1
+	mov_q	\tmp2, ~(SCTLR_ELx_ENIA | SCTLR_ELx_ENIB | \
+			SCTLR_ELx_ENDA | SCTLR_ELx_ENDB)
+	and	\tmp1, \tmp1, \tmp2
+	msr	sctlr_el1, \tmp1
+		// about to drop to EL0 which will give us an implicit isb
+.Ldont_disable\@:
+	.endm
+
+	.macro ptrauth_switch_to_kernel tsk, tmp1, tmp2, tmpw
+alternative_if_not ARM64_HAS_ADDRESS_AUTH
+	b	.Ldont_reenable\@
+alternative_else_nop_endif
+	mov	\tmp2, #THREAD_PTRAUTH_DISABLED
+	ldr	\tmpw, [\tsk, \tmp2]
+	cbz	\tmpw, .Ldont_reenable\@
+	mrs	\tmp1, sctlr_el1
+	mov_q	\tmp2, (SCTLR_ELx_ENIA | SCTLR_ELx_ENIB | \
+			SCTLR_ELx_ENDA | SCTLR_ELx_ENDB)
+	orr	\tmp1, \tmp1, \tmp2
+	msr	sctlr_el1, \tmp1
+	isb	// already in kernel mode, need context synchronising event
+.Ldont_reenable\@:
+	.endm
+
 #else /* CONFIG_ARM64_PTR_AUTH */
 
 	.macro ptrauth_keys_install_user tsk, tmp1, tmp2, tmp3
@@ -93,6 +125,11 @@ alternative_else_nop_endif
 	.macro ptrauth_keys_install_kernel tsk, tmp1, tmp2, tmp3
 	.endm
 
+	.macro ptrauth_switch_to_user tsk, tmp1, tmp2, tmpw
+	.endm
+
+	.macro ptrauth_switch_to_kernel tsk, tmp1, tmp2, tmpw
+	.endm
 #endif /* CONFIG_ARM64_PTR_AUTH */
 
 #endif /* __ASM_ASM_POINTER_AUTH_H */
diff --git a/arch/arm64/include/asm/pointer_auth.h b/arch/arm64/include/asm/pointer_auth.h
index c6b4f0603024..82993561ddc4 100644
--- a/arch/arm64/include/asm/pointer_auth.h
+++ b/arch/arm64/include/asm/pointer_auth.h
@@ -76,8 +76,12 @@ static inline unsigned long ptrauth_strip_insn_pac(unsigned long ptr)
 	return ptrauth_clear_pac(ptr);
 }
 
-#define ptrauth_thread_init_user(tsk)					\
-	ptrauth_keys_init_user(&(tsk)->thread.keys_user)
+#define ptrauth_thread_init_user(tsk, disabled)					\
+do {										\
+	ptrauth_keys_init_user(&(tsk)->thread.keys_user);			\
+	(tsk)->thread.ptrauth_disabled = disabled;				\
+} while (0)
+
 #define ptrauth_thread_init_kernel(tsk)					\
 	ptrauth_keys_init_kernel(&(tsk)->thread.keys_kernel)
 #define ptrauth_thread_switch_kernel(tsk)				\
@@ -86,7 +90,7 @@ static inline unsigned long ptrauth_strip_insn_pac(unsigned long ptr)
 #else /* CONFIG_ARM64_PTR_AUTH */
 #define ptrauth_prctl_reset_keys(tsk, arg)	(-EINVAL)
 #define ptrauth_strip_insn_pac(lr)	(lr)
-#define ptrauth_thread_init_user(tsk)
+#define ptrauth_thread_init_user(tsk, disabled)
 #define ptrauth_thread_init_kernel(tsk)
 #define ptrauth_thread_switch_kernel(tsk)
 #endif /* CONFIG_ARM64_PTR_AUTH */
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 240fe5e5b720..bb0b9edb5f9d 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -150,6 +150,7 @@ struct thread_struct {
 #ifdef CONFIG_ARM64_PTR_AUTH
 	struct ptrauth_keys_user	keys_user;
 	struct ptrauth_keys_kernel	keys_kernel;
+	unsigned int			ptrauth_disabled;
 #endif
 };
 
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 0577e2142284..eb686d9cf541 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -47,6 +47,7 @@ int main(void)
 #ifdef CONFIG_ARM64_PTR_AUTH
   DEFINE(THREAD_KEYS_USER,	offsetof(struct task_struct, thread.keys_user));
   DEFINE(THREAD_KEYS_KERNEL,	offsetof(struct task_struct, thread.keys_kernel));
+  DEFINE(THREAD_PTRAUTH_DISABLED,	offsetof(struct task_struct, thread.ptrauth_disabled));
 #endif
   BLANK();
   DEFINE(S_X0,			offsetof(struct pt_regs, regs[0]));
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 5304d193c79d..e3985521f763 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -180,6 +180,7 @@ alternative_cb_end
 	apply_ssbd 1, x22, x23
 
 	ptrauth_keys_install_kernel tsk, x20, x22, x23
+	ptrauth_switch_to_kernel tsk, x20, x22, w23
 
 	scs_load tsk, x20
 	.else
@@ -350,6 +351,7 @@ alternative_else_nop_endif
 
 	/* No kernel C function calls after this as user keys are set. */
 	ptrauth_keys_install_user tsk, x0, x1, x2
+	ptrauth_switch_to_user tsk, x0, x1, w2
 
 	apply_ssbd 0, x0, x1
 	.endif
@@ -920,6 +922,7 @@ SYM_FUNC_START(cpu_switch_to)
 	mov	sp, x9
 	msr	sp_el0, x1
 	ptrauth_keys_install_kernel x1, x8, x9, x10
+	ptrauth_switch_to_kernel x1, x8, x9, w10
 	scs_save x0, x8
 	scs_load x1, x8
 	ret
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 6089638c7d43..781f2b7bd986 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -580,6 +580,8 @@ unsigned long arch_align_stack(unsigned long sp)
 	return sp & ~0xf;
 }
 
+static unsigned int ptrauth_disabled;
+
 /*
  * Called from setup_new_exec() after (COMPAT_)SET_PERSONALITY.
  */
@@ -587,9 +589,36 @@ void arch_setup_new_exec(void)
 {
 	current->mm->context.flags = is_compat_task() ? MMCF_AARCH32 : 0;
 
-	ptrauth_thread_init_user(current);
+	ptrauth_thread_init_user(current, ptrauth_disabled);
+}
+
+#ifdef CONFIG_ARM64_PTR_AUTH
+
+static struct ctl_table ptrauth_disable_sysctl_table[] = {
+	{
+		.procname	= "ptrauth_disabled",
+		.mode		= 0644,
+		.data		= &ptrauth_disabled,
+		.maxlen		= sizeof(ptrauth_disabled),
+		.proc_handler	= proc_dointvec_minmax,
+		.extra1		= SYSCTL_ZERO,
+		.extra2		= SYSCTL_ONE,
+	},
+	{}
+
+};
+
+static int __init ptrauth_disable_init(void)
+{
+	if (!register_sysctl("abi", ptrauth_disable_sysctl_table))
+		return -EINVAL;
+	return 0;
 }
 
+core_initcall(ptrauth_disable_init);
+
+#endif /* CONFIG_ARM64_PTR_AUTH */
+
 #ifdef CONFIG_ARM64_TAGGED_ADDR_ABI
 /*
  * Control the relaxed ABI allowing tagged user addresses into the kernel.
-- 
2.25.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: Introduce sysctl to disable pointer authentication

[Will Deacon]

On Tue, Jul 07, 2020 at 06:32:32PM +0100, Steve Capper wrote:
> Pointer authentication is a mandatory feature in the Armv8.3
> architecture that provides protection against return oriented
> programming attacks. (meaning that all Arm CPUs targetting at least
> Armv8.3 will have this feature).
> 
> Once CONFIG_ARM64_PTR_AUTH=y, any systems with the hardware support for
> pointer authentication will automatically have it enabled by the kernel.
> 
> There are, however, situations where end users may want to disable
> pointer authentication. One could be tracking down/working around a bug
> in userspace relating to pointer auth. Also, one may wish to quantify
> the performance overhead of pointer auth by running a workload
> with/without it.

If you're debugging userspace, just recompile your userspace application
without ptr auth, in the same way that you might recompile with -g.

The performance argument sucks; this stuff needs to be fast otherwise it's
pointless. If you really need that last bit of speed, try Gentoo ;)

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: Introduce sysctl to disable pointer authentication

[Steve Capper]

Hi Will,

On Wed, Jul 08, 2020 at 08:36:21AM +0100, Will Deacon wrote:
> On Tue, Jul 07, 2020 at 06:32:32PM +0100, Steve Capper wrote:
> > Pointer authentication is a mandatory feature in the Armv8.3
> > architecture that provides protection against return oriented
> > programming attacks. (meaning that all Arm CPUs targetting at least
> > Armv8.3 will have this feature).
> > 
> > Once CONFIG_ARM64_PTR_AUTH=y, any systems with the hardware support for
> > pointer authentication will automatically have it enabled by the kernel.
> > 
> > There are, however, situations where end users may want to disable
> > pointer authentication. One could be tracking down/working around a bug
> > in userspace relating to pointer auth. Also, one may wish to quantify
> > the performance overhead of pointer auth by running a workload
> > with/without it.
> 
> If you're debugging userspace, just recompile your userspace application
> without ptr auth, in the same way that you might recompile with -g.
> 
> The performance argument sucks; this stuff needs to be fast otherwise it's
> pointless. If you really need that last bit of speed, try Gentoo ;)

I've tried Gentoo, and I liked it :-).

Apologies, I could have done a better job with the commit log...

I am trying to enable pointer authentication in distros. One concern I have
is that a pointer auth bug could slip through the cracks (with a lot of
hardware not yet supporting pointer auth), and then affect an end user.

Also, I have had interest from distros in the performance cost of pointer
auth, and there will very likely be folk switching it off/on again in
order to perform tests.

One approach to deploying this could be to have pointer auth disabled in
the kernel completely (via kconfig) and interested parties could then
switch kernels. Trouble with this is that distros ship single binaries so
it would be up to the end user to build/install another kernel + modules.
So this could be a barrier to adoption.

Having a mechanism in the kernel that an end user can employ to activate/
de-activate pointer auth would help with deployment greatly, and that is
what I was trying to achieve with this patch.

Another way to approach this could be via a kernel command line that
completely disables pointer auth? (i.e. kernel not activating pointer auth
at all, and userspace not seeing the feature)

Cheers,
-- 
Steve

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: Introduce sysctl to disable pointer authentication

[Will Deacon]

Hi Steve,

On Wed, Jul 08, 2020 at 02:46:52PM +0100, Steve Capper wrote:
> On Wed, Jul 08, 2020 at 08:36:21AM +0100, Will Deacon wrote:
> > On Tue, Jul 07, 2020 at 06:32:32PM +0100, Steve Capper wrote:
> > > Pointer authentication is a mandatory feature in the Armv8.3
> > > architecture that provides protection against return oriented
> > > programming attacks. (meaning that all Arm CPUs targetting at least
> > > Armv8.3 will have this feature).
> > > 
> > > Once CONFIG_ARM64_PTR_AUTH=y, any systems with the hardware support for
> > > pointer authentication will automatically have it enabled by the kernel.
> > > 
> > > There are, however, situations where end users may want to disable
> > > pointer authentication. One could be tracking down/working around a bug
> > > in userspace relating to pointer auth. Also, one may wish to quantify
> > > the performance overhead of pointer auth by running a workload
> > > with/without it.
> > 
> > If you're debugging userspace, just recompile your userspace application
> > without ptr auth, in the same way that you might recompile with -g.
> > 
> > The performance argument sucks; this stuff needs to be fast otherwise it's
> > pointless. If you really need that last bit of speed, try Gentoo ;)
> 
> I've tried Gentoo, and I liked it :-).

In fact, I used to use it as well but it's a total bugger if you forget
to update for a week or so. I remember an awful program called revdep-rebuild
or something. Dreadful stuff, but good fun (and, incidentally, what got me
interested in the kernel).

> Apologies, I could have done a better job with the commit log...

I've got to be honest, but the commit log smells of "I'm doing this because
somebody asked me to, not because I think it's a good idea"... Maybe I'm
wrong.

> I am trying to enable pointer authentication in distros. One concern I have
> is that a pointer auth bug could slip through the cracks (with a lot of
> hardware not yet supporting pointer auth), and then affect an end user.

Why is that different to any other feature we expose to userspace? Bugs
happen, and we deal with them.

> Also, I have had interest from distros in the performance cost of pointer
> auth, and there will very likely be folk switching it off/on again in
> order to perform tests.

And they can do that with the compiler at the same time as they pass
-funsafe-math -Ofast.

> One approach to deploying this could be to have pointer auth disabled in
> the kernel completely (via kconfig) and interested parties could then
> switch kernels. Trouble with this is that distros ship single binaries so
> it would be up to the end user to build/install another kernel + modules.
> So this could be a barrier to adoption.

Shipping multiple kernels is a non-starter, but I fail to see why that
is even a consideration given that this really isn't a kernel problem
afaict.

> Having a mechanism in the kernel that an end user can employ to activate/
> de-activate pointer auth would help with deployment greatly, and that is
> what I was trying to achieve with this patch.
> 
> Another way to approach this could be via a kernel command line that
> completely disables pointer auth? (i.e. kernel not activating pointer auth
> at all, and userspace not seeing the feature)

I did wonder briefly about overriding the sanitised ID registers on the
command-line, but I think it opens a door that we'll regret opening later
on.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: Introduce sysctl to disable pointer authentication

[Jeremy Linton]

Hi,

On 7/8/20 5:08 PM, Will Deacon wrote:
> Hi Steve,
> 
> On Wed, Jul 08, 2020 at 02:46:52PM +0100, Steve Capper wrote:
>> On Wed, Jul 08, 2020 at 08:36:21AM +0100, Will Deacon wrote:
>>> On Tue, Jul 07, 2020 at 06:32:32PM +0100, Steve Capper wrote:
>>>> Pointer authentication is a mandatory feature in the Armv8.3
>>>> architecture that provides protection against return oriented
>>>> programming attacks. (meaning that all Arm CPUs targetting at least
>>>> Armv8.3 will have this feature).
>>>>
>>>> Once CONFIG_ARM64_PTR_AUTH=y, any systems with the hardware support for
>>>> pointer authentication will automatically have it enabled by the kernel.
>>>>
>>>> There are, however, situations where end users may want to disable
>>>> pointer authentication. One could be tracking down/working around a bug
>>>> in userspace relating to pointer auth. Also, one may wish to quantify
>>>> the performance overhead of pointer auth by running a workload
>>>> with/without it.
>>>
>>> If you're debugging userspace, just recompile your userspace application
>>> without ptr auth, in the same way that you might recompile with -g >>>
>>> The performance argument sucks; this stuff needs to be fast otherwise it's
>>> pointless. If you really need that last bit of speed, try Gentoo ;)
>>
>> I've tried Gentoo, and I liked it :-).
> 
> In fact, I used to use it as well but it's a total bugger if you forget
> to update for a week or so. I remember an awful program called revdep-rebuild
> or something. Dreadful stuff, but good fun (and, incidentally, what got me
> interested in the kernel).
> 
>> Apologies, I could have done a better job with the commit log...
> 
> I've got to be honest, but the commit log smells of "I'm doing this because
> somebody asked me to, not because I think it's a good idea"... Maybe I'm
> wrong. >
>> I am trying to enable pointer authentication in distros. One concern I have
>> is that a pointer auth bug could slip through the cracks (with a lot of
>> hardware not yet supporting pointer auth), and then affect an end user.
> 
> Why is that different to any other feature we expose to userspace? Bugs
> happen, and we deal with them.
> 
>> Also, I have had interest from distros in the performance cost of pointer
>> auth, and there will very likely be folk switching it off/on again in
>> order to perform tests.
> 
> And they can do that with the compiler at the same time as they pass
> -funsafe-math -Ofast.

So, a bit of background. Pointer auth has been accepted as a systemwide 
change for Fedora 33. That acceptance requires contingency planning for 
what to do if the feature is causing ship blocking/etc defects. While we 
are going to do our best to test it before release, as your aware, the 
8.3+ machines are in short supply. Most of the community testing & 
debugging will simply be to assure that we don't break anything on v8.0 
machines. Which means that its quite likely that the bugs are going to 
be reported by end users with 8.3+ hardware who don't compile their own 
packages, nor debug them (and the idea that we can get any kind of 
coverage on tens of thousands of packages is crazy). Given many of the 
bugs so far have been subtle glibc/gcc/etc they are also far ranging. 
So, being able to give the end user a simple way to a->b test whether a 
problem goes away helps us to triage whether we are looking at a generic 
bug, or one related to pointer auth (or for that matter an active 
attack). Further, should it happen to something during the boot process 
(which is significantly more complex on fedora than the usual 
kernel+busybox+disk image) then we need a straightforward method to boot 
the end users machines so they can in-place install/upgrade/test.

In summary I see this sort of similar to selinux=0, a flag that no one 
should be using, but is still frequently used because its required just 
to boot a machine in order to fix a problem.

> 
>> One approach to deploying this could be to have pointer auth disabled in
>> the kernel completely (via kconfig) and interested parties could then
>> switch kernels. Trouble with this is that distros ship single binaries so
>> it would be up to the end user to build/install another kernel + modules.
>> So this could be a barrier to adoption.
> 
> Shipping multiple kernels is a non-starter, but I fail to see why that
> is even a consideration given that this really isn't a kernel problem
> afaict.

We need a way to ship all the PAC enabled binary artifacts but assure 
they can be quickly/easily reverted to pre 8.3 pointer auth code paths, 
which have been more heavily tested. Rebuilding the entire distro to 
globally disable pointer auth is a non starter, particularly after it 
has shipped.


> 
>> Having a mechanism in the kernel that an end user can employ to activate/
>> de-activate pointer auth would help with deployment greatly, and that is
>> what I was trying to achieve with this patch.
>>
>> Another way to approach this could be via a kernel command line that
>> completely disables pointer auth? (i.e. kernel not activating pointer auth
>> at all, and userspace not seeing the feature)
> 
> I did wonder briefly about overriding the sanitised ID registers on the
> command-line, but I think it opens a door that we'll regret opening later
> on.
> 
> Will
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: Introduce sysctl to disable pointer authentication

[Catalin Marinas]

On Wed, Jul 08, 2020 at 11:08:06PM +0100, Will Deacon wrote:
> On Wed, Jul 08, 2020 at 02:46:52PM +0100, Steve Capper wrote:
> > On Wed, Jul 08, 2020 at 08:36:21AM +0100, Will Deacon wrote:
> > > On Tue, Jul 07, 2020 at 06:32:32PM +0100, Steve Capper wrote:
> > > > Pointer authentication is a mandatory feature in the Armv8.3
> > > > architecture that provides protection against return oriented
> > > > programming attacks. (meaning that all Arm CPUs targetting at least
> > > > Armv8.3 will have this feature).
> > > > 
> > > > Once CONFIG_ARM64_PTR_AUTH=y, any systems with the hardware support for
> > > > pointer authentication will automatically have it enabled by the kernel.
> > > > 
> > > > There are, however, situations where end users may want to disable
> > > > pointer authentication. One could be tracking down/working around a bug
> > > > in userspace relating to pointer auth. Also, one may wish to quantify
> > > > the performance overhead of pointer auth by running a workload
> > > > with/without it.
[...]
> > Having a mechanism in the kernel that an end user can employ to activate/
> > de-activate pointer auth would help with deployment greatly, and that is
> > what I was trying to achieve with this patch.
> > 
> > Another way to approach this could be via a kernel command line that
> > completely disables pointer auth? (i.e. kernel not activating pointer auth
> > at all, and userspace not seeing the feature)
> 
> I did wonder briefly about overriding the sanitised ID registers on the
> command-line, but I think it opens a door that we'll regret opening later
> on.

I had attempted it in these two patches (together with the DT support):

https://lore.kernel.org/linux-arm-kernel/20200515171612.1020-24-catalin.marinas@arm.com/
https://lore.kernel.org/linux-arm-kernel/20200515171612.1020-25-catalin.marinas@arm.com/

(both patches now dropped; we have a way to disable the tagged addr ABI
already and reject the prctl() call)

Overriding the ID regs disables the feature for both user and kernel.
IIUC, Steve only wanted this disabled for user.

A light concern with this patch is that it still keeps the HWCAP around,
only that it makes this instructions behave as NOPs. So that would be a
deviation from what the HWCAP bit actually implies. From this
perspective, a big knob may be a cleaner option.

Anyway, I agree that opening the door would lead to more such requests
in the future. We should only do this if there is a high risk of the
feature going terribly wrong in the user space out there. AFAICT, that's
not entirely clear at the moment. Distros could carry such patch
temporarily and, if proven useful in the long run, we can revisit the
upstreaming story.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel