[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