[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu-9M0yO-rSXiREs11feEro0mJFcNN3Wkp_LSOGrKKd5dg@mail.gmail.com>
Date: Mon, 6 Aug 2018 21:35:53 +0200
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Kees Cook <keescook@...omium.org>
Cc: Robin Murphy <robin.murphy@....com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>, Mark Rutland <mark.rutland@....com>,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>,
Christoffer Dall <christoffer.dall@....com>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Laura Abbott <labbott@...oraproject.org>, Julien Thierry <julien.thierry@....com>
Subject: Re: [RFC/PoC PATCH 0/3] arm64: basic ROP mitigation
On 6 August 2018 at 20:49, Kees Cook <keescook@...omium.org> wrote:
> On Mon, Aug 6, 2018 at 10:45 AM, Robin Murphy <robin.murphy@....com> wrote:
>> I guess what I'm getting at is that if the protection mechanism is "always
>> return with SP outside TTBR1", there seems little point in going through the
>> motions if SP in TTBR0 could still be valid and allow an attack to succeed
>> anyway; this is basically just me working through a justification for saying
>> the proposed scheme needs "depends on ARM64_PAN || ARM64_SW_TTBR0_PAN",
>> making it that much uglier for v8.0 CPUs...
>
> I think anyone with v8.0 CPUs interested in this mitigation would also
> very much want PAN emulation. If a "depends on" isn't desired, what
> about "imply" in the Kconfig?
>
Yes, but actually, using bit #0 is maybe a better alternative in any
case. You can never dereference SP with bit #0 set, regardless of
whether the address points to user or kernel space, and my concern
about reloading sp from x29 doesn't really make sense, given that x29
is always assigned from sp right after pushing x29 and x30 in the
function prologue, and sp only gets restored from x29 in the epilogue
when there is a stack frame to begin with, in which case we add #1 to
sp again before returning from the function.
The other code gets a lot cleaner as well.
So for the return we'll have
ldp x29, x30, [sp], #nn
>>add sp, sp, #0x1
ret
and for the function call
bl <foo>
>>mov x30, sp
>>bic sp, x30, #1
The restore sequence in entry.s:96 (which has no spare registers) gets
much simpler as well:
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -95,6 +95,15 @@ alternative_else_nop_endif
*/
add sp, sp, x0 // sp' = sp + x0
sub x0, sp, x0 // x0' = sp' - x0 = (sp + x0) - x0 = sp
+#ifdef CONFIG_ARM64_ROP_SHIELD
+ tbnz x0, #0, 1f
+ .subsection 1
+1: sub x0, x0, #1
+ sub sp, sp, #1
+ b 2f
+ .previous
+2:
+#endif
tbnz x0, #THREAD_SHIFT, 0f
sub x0, sp, x0 // x0'' = sp' - x0' = (sp + x0) - sp = x0
sub sp, sp, x0 // sp'' = sp' - x0 = (sp + x0) - x0 = sp
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.
