Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751998AbdCOGbr (ORCPT ); Wed, 15 Mar 2017 02:31:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49372 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751878AbdCOGbq (ORCPT ); Wed, 15 Mar 2017 02:31:46 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0F6FE3D94D Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bhe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 0F6FE3D94D Date: Wed, 15 Mar 2017 14:31:42 +0800 From: Baoquan He To: linux-kernel@vger.kernel.org Cc: linux-efi@vger.kernel.org, thgarnie@google.com, keescook@chromium.org, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, bp@suse.de, dyoung@redhat.com Subject: Re: [PATCH 2/2] x86/mm/KASLR: Correct the upper boundary of KALSR mm regions if adjacent to EFI Message-ID: <20170315063142.GC1938@x1> References: <1488959258-4731-1-git-send-email-bhe@redhat.com> <1488959258-4731-2-git-send-email-bhe@redhat.com> <20170315061357.GB1938@x1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170315061357.GB1938@x1> User-Agent: Mutt/1.7.0 (2016-08-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 15 Mar 2017 06:31:46 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2250 Lines: 62 On 03/15/17 at 02:13pm, Baoquan He wrote: > PING! > > Is there any suggestion for this code bug fix? > > Boris added comment in patch 1/2 thread that it can also be fixed by > swapping the naming - EFI_VA_START and EFI_VA_END. As he said the > swapping can remove the confusion about the naming, while the con is > changing it now could confuse more people who have the current > mental picture of the mapping direction. If swapping the naming is suggested, I can post v2 to change efi code. Both of them is fine to me. > > And there's also a well known similar use case, stack, like stack_end > naming in arch/x86/boot/main.c which is the low addr boundary of stack > region. > > Any idea? > > Thanks > Baoquan > > On 03/08/17 at 03:47pm, Baoquan He wrote: > > EFI allocates runtime services regions top-down, starting from EFI_VA_START > > to EFI_VA_END. So EFI_VA_START is bigger than EFI_VA_END and is the end of > > EFI region. The upper boundary of memory regions randomized by KASLR should > > be EFI_VA_END if it's adjacent to EFI region, but not EFI_VA_START. > > > > Correct it in this patch. > > > > Signed-off-by: Baoquan He > > --- > > arch/x86/mm/kaslr.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c > > index 887e571..aed2064 100644 > > --- a/arch/x86/mm/kaslr.c > > +++ b/arch/x86/mm/kaslr.c > > @@ -48,7 +48,7 @@ static const unsigned long vaddr_start = __PAGE_OFFSET_BASE; > > #if defined(CONFIG_X86_ESPFIX64) > > static const unsigned long vaddr_end = ESPFIX_BASE_ADDR; > > #elif defined(CONFIG_EFI) > > -static const unsigned long vaddr_end = EFI_VA_START; > > +static const unsigned long vaddr_end = EFI_VA_END; > > #else > > static const unsigned long vaddr_end = __START_KERNEL_map; > > #endif > > @@ -105,7 +105,7 @@ void __init kernel_randomize_memory(void) > > */ > > BUILD_BUG_ON(vaddr_start >= vaddr_end); > > BUILD_BUG_ON(IS_ENABLED(CONFIG_X86_ESPFIX64) && > > - vaddr_end >= EFI_VA_START); > > + vaddr_end >= EFI_VA_END); > > BUILD_BUG_ON((IS_ENABLED(CONFIG_X86_ESPFIX64) || > > IS_ENABLED(CONFIG_EFI)) && > > vaddr_end >= __START_KERNEL_map); > > -- > > 2.5.5 > >