Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751669AbdCOGOD (ORCPT ); Wed, 15 Mar 2017 02:14:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51580 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750848AbdCOGOC (ORCPT ); Wed, 15 Mar 2017 02:14:02 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 06AED80F6D Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bhe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 06AED80F6D Date: Wed, 15 Mar 2017 14:13:57 +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, 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: <20170315061357.GB1938@x1> References: <1488959258-4731-1-git-send-email-bhe@redhat.com> <1488959258-4731-2-git-send-email-bhe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1488959258-4731-2-git-send-email-bhe@redhat.com> 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.27]); Wed, 15 Mar 2017 06:14:02 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1993 Lines: 57 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. 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 >