Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Aug 2018 18:04:30 +0200
From: Ard Biesheuvel <>
To: Robin Murphy <>
Cc: Kernel Hardening <>, 
	Mark Rutland <>, Kees Cook <>, 
	Catalin Marinas <>, Will Deacon <>, 
	Christoffer Dall <>, 
	linux-arm-kernel <>, 
	Laura Abbott <>, Julien Thierry <>
Subject: Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation

On 6 August 2018 at 17:50, Ard Biesheuvel <> wrote:
> On 6 August 2018 at 17:38, Robin Murphy <> wrote:
>> On 06/08/18 15:04, Ard Biesheuvel wrote:
>>> On 6 August 2018 at 15:55, Robin Murphy <> 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.
> Wouldn't such an epilogue clear the SP bit before returning again?

... or are you saying you can play tricks and clear bits 52 .. 54 ? If
so, you can already do that, right? And apply it to bit 55 as well?

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.