From mboxrd@z Thu Jan  1 00:00:00 1970
From: will.deacon@arm.com (Will Deacon)
Date: Fri, 19 Oct 2018 13:22:05 +0100
Subject: [PATCH v5 11/17] arm64: docs: document pointer authentication
In-Reply-To: <20181019113556.ljbdmjo5pdw7muvz@mbp>
References: <20181005084754.20950-1-kristina.martsenko@arm.com>
 <20181005084754.20950-12-kristina.martsenko@arm.com>
 <9acb0cd2-66b0-1c41-b1a8-7c70608e9a9b@foss.arm.com>
 <7b0de19b-45b9-f4df-25d1-c7e80fab49dc@arm.com>
 <20181019113556.ljbdmjo5pdw7muvz@mbp>
Message-ID: <20181019122204.GE14246@arm.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Fri, Oct 19, 2018 at 12:35:56PM +0100, Catalin Marinas wrote:
> On Tue, Oct 16, 2018 at 05:14:39PM +0100, Kristina Martsenko wrote:
> > On 05/10/2018 10:04, Ramana Radhakrishnan wrote:
> > > On 05/10/2018 09:47, Kristina Martsenko wrote:
> > The other special case is the XPACLRI instruction, which is also in the
> > HINT space. Currently it will trap and KVM will inject an exception into
> > the guest. We should probably change this to NOP instead, as that's what
> > applications will expect. Unfortunately there is no EnIA-like control to
> > make it NOP.
> 
> Very good catch. Basically if EL2 doesn't know about ptr auth (older
> distro), EL1 may or may not know but leaves SCTLR_EL1 disabled (based on
> CPUID), the default HCR_EL2 is to trap (I'm ignoring EL3 as that's like
> to have ptr auth enabled, being built for the specific HW). So a user
> app considering XPACLRI a NOP (or inoffensive) will get a SIGILL
> (injected by the guest kernel following the injection of "Unknown
> reason" exception by KVM).
> 
> Ramana, is XPACLRI commonly generated by gcc and expects it to be a NOP?
> Could we restrict it to only being used at run-time if the corresponding
> HWCAP is set? This means redefining this instruction as no longer in the
> NOP space.

My main worry is that this instruction is used when unwinding C++
exceptions, so I think we'll see it fairly often.

Effectively, the architecture means these instructions can result in a
SIGILL if they are used under an OS/hypervisor that doesn't know about
the feature (i.e. any mainline kernel release so far). I think that's a
massive problem for the current implementation in GCC. Worse, if
distributions are currently shipping binaries built with this, they
basically have a ticking bomb in their applications where things will
start crashing when they encounter CPUs that implement pointer
authentication.

Ramana: do you know whether people are building binaries with this stuff
enabled by default?

Will