[lkml]   [2017]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [kernel-hardening] [PATCH] lkdtm: Test VMAP_STACK allocates leading/trailing guard pages
On 7 August 2017 at 22:44, Kees Cook <> wrote:
> On Mon, Aug 7, 2017 at 2:27 PM, Ard Biesheuvel
> <> wrote:
>> On 7 August 2017 at 21:39, Kees Cook <> wrote:
>>> 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 <>
>>> ---
>>> 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.

 \ /
  Last update: 2017-08-07 23:47    [W:0.049 / U:0.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site