Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752096AbdHGVqT (ORCPT ); Mon, 7 Aug 2017 17:46:19 -0400 Received: from mail-it0-f53.google.com ([209.85.214.53]:37595 "EHLO mail-it0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751662AbdHGVqR (ORCPT ); Mon, 7 Aug 2017 17:46:17 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170807203948.GA22298@beast> From: Ard Biesheuvel Date: Mon, 7 Aug 2017 22:46:16 +0100 Message-ID: Subject: Re: [kernel-hardening] [PATCH] lkdtm: Test VMAP_STACK allocates leading/trailing guard pages To: Kees Cook Cc: "linux-kernel@vger.kernel.org" , Mark Rutland , Catalin Marinas , James Morse , Laura Abbott , Andy Lutomirski , Matt Fleming , Will Deacon , Kernel Hardening , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1502 Lines: 31 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: >>> 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 >>> --- >>> 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.