linux-kernel - Re: [PATCH v3 2/2] efi: efi_mem_reserve(): don't reserve 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: <20170109130033.GH16838@codeblueprint.co.uk>
Date:   Mon, 9 Jan 2017 13:00:33 +0000
From:   Matt Fleming <matt@...eblueprint.co.uk>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Nicolai Stange <nicstange@...il.com>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        "x86@...nel.org" <x86@...nel.org>,
        Mika Penttilä <mika.penttila@...tfour.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Dave Young <dyoung@...hat.com>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/2] efi: efi_mem_reserve(): don't reserve through
 memblock after mm_init()

On Fri, 06 Jan, at 07:28:40PM, Ard Biesheuvel wrote:
> 
> This is my point exactly. But it appears efi_free_boot_services()
> occurs much later than I thought, and so there is a sizabe time window
> where SLAB is up but reservations can still be made. But we don't
> check whether efi_free_boot_services() has been called.

True. This has only been correct thus far because all code has been
audited, but adding a check to catch future offenders is a good idea.

> Another problem is that we never check that the reservation is
> covered by a BootServicesData region, which are the only ones that
> are guaranteed to be retained up to this point.

The runtime regions are guaranteed to be retained too.

Again, this shouldn't actually be a problem today, but the potential
for breakage here warrants some kind of check and loud warning.