linux-kernel - Re: [PATCH] x86/boot: Reorganize and clean up the BIOS area reservation code

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:	Fri, 22 Jul 2016 14:00:07 +0100
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Mario Limonciello <mario_limonciello@...l.com>,
	Kees Cook <keescook@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	X86 ML <x86@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Josh Triplett <josh@...htriplett.org>,
	Peter Jones <pjones@...hat.com>
Subject: Re: [PATCH] x86/boot: Reorganize and clean up the BIOS area
 reservation code

On Thu, 21 Jul, at 03:45:14PM, Andy Lutomirski wrote:
> 
> I looked at the code some more.  The boot services quirk is weird and
> maybe buggy.  trim_snb_memory uses memblock_reserve to reserve the
> bottom 1MB.  If efi_reserve_real_mode has already reserved that range,
> then trim_snb_memory's reservation will have no effect because the efi
> code will just free it later on.  The same issue will hit any code
> that reserves >1MB memory after efi has tried to temporarily reserve
> it.

Yeah, that looks like a bug. memblock_reserve() reference counting,
anyone?

> I don't have any great suggestions for cleaning it up.  Perhaps the
> efi code should instead skip adding boot services memory to the memory
> map in the first place and then add it late and hand any unreserved
> bits to the buddy allocator?

The issue is that some data required at runtime may be contained in
those boot services data regions; the EFI System Resource Table is a
good example or the ACPI BGRT table. esrt_init() happens pretty early
but efi_bgrt_init() is really late in boot because we need the ACPI
subsystem to have been brought up.

Fundamentally, you can't know whether you can use the boot services
regions for allocation until after SetVirtualAddressMap() has been
called (the original bug that required the reservation quirks occurs
at SVAM time) and after drivers have read the EFI config tables and
marked their regions as reserved.

I suppose we could rewrite the page table mapping for those precious
<1MB regions to coerce the firmware into accessing different pages
instead of the 1:1 addresses and copy the regions elsewhere. Maybe.
That assumes we don't hit other firmware bugs though.