[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu9QPnSwOqtBkg9kPq2_UONRfOOJusw0_U59BWLW2=YbUw@mail.gmail.com>
Date: Mon, 7 Aug 2017 22:46:16 +0100
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Kees Cook <keescook@...omium.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Mark Rutland <mark.rutland@....com>,
Catalin Marinas <catalin.marinas@....com>, James Morse <james.morse@....com>,
Laura Abbott <labbott@...hat.com>, Andy Lutomirski <luto@...capital.net>,
Matt Fleming <matt@...eblueprint.co.uk>, Will Deacon <will.deacon@....com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] lkdtm: Test VMAP_STACK allocates
leading/trailing guard pages
On 7 August 2017 at 22:44, Kees Cook <keescook@...omium.org> wrote:
> On Mon, Aug 7, 2017 at 2:27 PM, Ard Biesheuvel
> <ard.biesheuvel@...aro.org> wrote:
>> On 7 August 2017 at 21:39, Kees Cook <keescook@...omium.org> wrote:
>>> Two new tests STACK_GUARD_PAGE_LEADING and STACK_GUARD_PAGE_TRAILING
>>> attempt to read the byte before and after, respectively, of the current
>>> stack frame, which should fault under VMAP_STACK.
>>>
>>> Signed-off-by: Kees Cook <keescook@...omium.org>
>>> ---
>>> Do these tests both trip with the new arm64 VMAP_STACK code?
>>
>> Probably not. On arm64, the registers are stacked by software at
>> exception entry, and so we decrement the sp first by the size of the
>> register file, and if the resulting value overflows the stack, the
>> situation is handled as if the exception was caused by a faulting
>> stack access while it may be caused by something else in reality.
>> Since the act of handling the exception is guaranteed to overflow the
>> stack anyway, this does not really make a huge difference, and it
>> prevents the recursive fault from wiping the context that we need to
>> produce the diagnostics.
>>
>> This means an illegal access right above the stack will go undetected.
>
> I thought vmap entries provided guard pages around allocations?
> Shouldn't that catch it?
>
Ah yes, so we will fault. We should probably double check whether we
will not misidentify the fault because of the subtraction we do first,
but that should be trivial to add.
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.
