linux-kernel - Re: [PATCH 00/11] ARMv8.3 pointer authentication userspace support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170725160116.GB12749@leverpostej>
Date:   Tue, 25 Jul 2017 17:01:16 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Yao Qi <yao.qi@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, arnd@...db.de,
        catalin.marinas@....com, christoffer.dall@...aro.org,
        Dave.Martin@....com, jiong.wang@....com,
        kvmarm@...ts.cs.columbia.edu, linux-arch@...r.kernel.org,
        marc.zyngier@....com, suzuki.poulose@....com, will.deacon@....com,
        linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 00/11] ARMv8.3 pointer authentication userspace support

Hi,

On Tue, Jul 25, 2017 at 12:32:10PM +0100, Yao Qi wrote:
> On 19/07/17 17:01, Mark Rutland wrote:
> > If authentication fails, bits are set in the pointer such that it is
> > guaranteed to cause a fault if used.
> 
> How does user space know the fault is caused by authentication fail?

Strictly speaking, it does not, and neither does the kernel.

In general, it cannot know whether this is the case, as an
authentication failure does not result in an immediate exception.

> When GDB is debugging a program, and it failed in pointer
> authentication, I assume GDB only knows that the program receives signal
> SIGSEGV, but how does GDB or user know why does the program get SIGSEGV?

I think in practice, the user has to determine this for themselves. I do
not believe that it is possible to reliably determine whether a given
fault was caused by an authentication failure.

For example, consider an authentication failure in a function epilogue:

	ldp	x29, x30, [sp], #FRAME_SIZE
	autiasp
	ret

When AUTIASP fails to authenticate the x30 value, it ensures that x30 is
a faulting value, by forcing some of the high bits to particular values,
but that's all. A user can set those bits in the same way.

The RET loads the LR value into the PC, which subsequently triggers an
instruction abort for the PC value (i.e. we branch to the bogus address
*then* take a fault at that address).

At that point, we have no information to determine what the CPU was
executing before it branched to the bogus address. So we cannot know how
the address was generated, and therefore cannot know if it was an
authentication failure.

For data pointers, you could generate bogus pointers with a large
out-of-bounds array index, whereby the bogus pointer looked like the
result of a pointer authentication failure.

Thanks,
Mark.