DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 831C2552DC
Date: Wed, 26 Jul 2017 09:34:32 +0800
From: Baoquan He <bhe@redhat.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>,
        Kees Cook <keescook@chromium.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>,
        Ingo Molnar <mingo@kernel.org>,
        "izumi.taku@jp.fujitsu.com" <izumi.taku@jp.fujitsu.com>,
        Thomas Garnier <thgarnie@google.com>,
        "fanc.fnst@cn.fujitsu.com" <fanc.fnst@cn.fujitsu.com>,
        Junichi Nomura <j-nomura@ce.jp.nec.com>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>, dyoung@redhat.com
Subject: Re: [PATCH v3 2/2] x86/efi: clean up dead code around
 efi_reserve_boot_services()
Message-ID: <20170726013432.GA1117@x1>
References: <20170710054733.GA22619@hori1.linux.bs1.fc.nec.co.jp>
 <1499665896-23731-2-git-send-email-n-horiguchi@ah.jp.nec.com>
 <20170724132044.GB11076@codeblueprint.co.uk>
 <20170726001230.GA32325@hori1.linux.bs1.fc.nec.co.jp>
 <20170726011331.GA24304@x1>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170726011331.GA24304@x1>
User-Agent: Mutt/1.7.0 (2016-08-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1642
Lines: 32

On 07/26/17 at 09:13am, Baoquan He wrote:
> On 07/26/17 at 12:12am, Naoya Horiguchi wrote:
> > On Mon, Jul 24, 2017 at 02:20:44PM +0100, Matt Fleming wrote:
> > > On Mon, 10 Jul, at 02:51:36PM, Naoya Horiguchi wrote:
> > > > EFI_BOOT_SERVICES_{CODE|DATA} regions never overlap the kernel now,
> > > > so we can clean up the check in efi_reserve_boot_services().
> > > > 
> > > > Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> > > > ---
> > > >  arch/x86/platform/efi/quirks.c | 23 +----------------------
> > > >  1 file changed, 1 insertion(+), 22 deletions(-)
> > > 
> > > Is this true for kernels not using KASLR? 
> > 
> > Thank you for pointing out this. It's not true depending on memmap layout.
> > If a firmware does not define the memory around the kernel address
> > (0x1000000 or CONFIG_PHYSICAL_START) as EFI_BOOT_SERVICES_*, no overlap
> > happens.  That's true in my testing server, but I don't think that we can
> > expect it generally.
> > 
> > So I think of adding some assertion in the patch 1/2 to detect this overlap
> > in extract_kernel() even for no KASLR case.
> 
> EFI_BOOT_SERVICES_* memory are collected as e820 region of
> E820_TYPE_RAM, how can we guarantee kernel won't use them after jumping
> into the running kernel whether KASLR enabled or not? We can only wish
> that EFI firmware engineer don't put EFI_BOOT_SERVICES_* far from
					sorry, typo.  I meant EFI boot
service region need be put far from 0x1000000. Otherwise normal kernel could
allocate memory bottom up and stomp on them. It's embarassment caused by
the hardware flaw of x86 platfrom.
> 0x1000000 where normal kernel is loaded.