linux-kernel - Re: [PATCH v2 1/2] x86/efi: don't allocate memmap through memblock after mm

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20170105074221.GA1777@gmail.com>
Date:   Thu, 5 Jan 2017 08:42:21 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Nicolai Stange <nicstange@...il.com>
Cc:     Matt Fleming <matt@...eblueprint.co.uk>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mika Penttilä <mika.penttila@...tfour.com>,
        Dan Williams <dan.j.williams@...el.com>
Subject: Re: [PATCH v2 1/2] x86/efi: don't allocate memmap through memblock
 after mm_init()


* Nicolai Stange <nicstange@...il.com> wrote:

> Matt Fleming <matt@...eblueprint.co.uk> writes:
> 
> > On Thu, 22 Dec, at 11:23:39AM, Nicolai Stange wrote:
> >> So, after memblock is gone, allocations should be done through the "normal"
> >> page allocator. Introduce a helper, efi_memmap_alloc() for this. Use
> >> it from efi_arch_mem_reserve() and from efi_free_boot_services() as well.
> >> 
> >> Fixes: 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data")
> >> Signed-off-by: Nicolai Stange <nicstange@...il.com>
> 
> > Could you also modify efi_fake_memmap() to use your new
> > efi_memmap_alloc() function for consistency
> 
> Sure.
> 
> I'm planning to submit another set of patches addressing the (bounded)
> memmap leaking in anything calling efi_memmap_unmap() though. In the
> course of doing so, the memmap allocation sites will get touched anyway:
> I'll have to store some information about how the memmap's memory has
> been obtained.

Will that patch be intrusive?

If yes then we'll need to keep this a separate urgent patch to fix the v4.9 
regression that Dan Williams reported. I can apply the fix to efi/urgent and get 
it to Linus straight away if you guys agree.

Thanks,

	Ingo