[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
>