linux-kernel - Re: [PATCH v3 2/2] x86/efi: clean up dead code around efi_reserve_boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 Jul 2017 09:34:32 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Naoya Horiguchi <n-horiguchi@...jp.nec.com>
Cc:     Matt Fleming <matt@...eblueprint.co.uk>,
        Kees Cook <keescook@...omium.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
        "izumi.taku@...fujitsu.com" <izumi.taku@...fujitsu.com>,
        Thomas Garnier <thgarnie@...gle.com>,
        "fanc.fnst@...fujitsu.com" <fanc.fnst@...fujitsu.com>,
        Junichi Nomura <j-nomura@...jp.nec.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>, dyoung@...hat.com
Subject: Re: [PATCH v3 2/2] x86/efi: clean up dead code around
 efi_reserve_boot_services()

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@...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.