[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