Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation

[Robin Murphy <robin.murphy@arm.com>]

On 06/08/18 15:04, Ard Biesheuvel wrote:
> On 6 August 2018 at 15:55, Robin Murphy <robin.murphy@arm.com> wrote:
>> On 02/08/18 14:21, Ard Biesheuvel wrote:
>>>
>>> This is a proof of concept I cooked up, primarily to trigger a discussion
>>> about whether there is a point to doing anything like this, and if there
>>> is, what the pitfalls are. Also, while I am not aware of any similar
>>> implementations, the idea is so simple that I would be surprised if nobody
>>> else thought of the same thing way before I did.
>>
>>
>> So, "TTBR0 PAN: Pointer Auth edition"? :P
>>
>>> The idea is that we can significantly limit the kernel's attack surface
>>> for ROP based attacks by clearing the stack pointer's sign bit before
>>> returning from a function, and setting it again right after proceeding
>>> from the [expected] return address. This should make it much more
>>> difficult
>>> to return to arbitrary gadgets, given that they rely on being chained to
>>> the next via a return address popped off the stack, and this is difficult
>>> when the stack pointer is invalid.
>>>
>>> Of course, 4 additional instructions per function return is not exactly
>>> for free, but they are just movs and adds, and leaf functions are
>>> disregarded unless they allocate a stack frame (this comes for free
>>> because simple_return insns are disregarded by the plugin)
>>>
>>> Please shoot, preferably with better ideas ...
>>
>>
>> Actually, on the subject of PAN, shouldn't this at least have a very hard
>> dependency on that? AFAICS without PAN clearing bit 55 of SP is effectively
>> giving userspace direct control of the kernel stack (thanks to TBI). Ouch.
>>
> 
> How's that? Bits 52 .. 54 will still be set, so SP will never contain
> a valid userland address in any case. Or am I missing something?

Ah, yes, I'd managed to forget about the address hole, but I think that 
only makes it a bit trickier, rather than totally safe - it feels like 
you just need to chain one or two returns through "valid" targets until 
you can hit an epilogue with a "mov sp, x29" (at first glance there are 
a fair few of those in my vmlinux), after which we're back to the bit 55 
scheme alone giving no protection against retargeting the stack to a 
valid TTBR0 address.

>> I wonder if there's a little  more mileage in using "{add,sub} sp, sp, #1"
>> sequences to rely on stack alignment exceptions instead, with the added
>> bonus that that's about as low as the instruction-level overhead can get.
>>
> 
> Good point. I did consider that, but couldn't convince myself that it
> isn't easier to defeat: loads via x29 occur reasonably often, and you
> can simply offset your doctored stack frame by a single byte.

True; in theory there are 3072 possible unaligned offsets to choose 
from, but compile-time randomisation doesn't seem much use, and 
hotpatching just about every function call in the kernel isn't a nice 
thought either.

Robin.