linux-kernel - Re: [PATCH 0/3] Fix ACPI BGRT support for images located in EFI boot services memory

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: <5046442E.7020207@zytor.com>
Date:	Tue, 04 Sep 2012 11:10:54 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Josh Triplett <josh@...htriplett.org>
CC:	Matt Fleming <matt.fleming@...el.com>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	Len Brown <lenb@...nel.org>, Olof Johansson <olof@...om.net>,
	Matthew Garrett <mjg@...hat.com>,
	David Howells <dhowells@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jim Cromie <jim.cromie@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Pawel Moll <pawel.moll@....com>, linux-acpi@...r.kernel.org,
	linux-efi <linux-efi@...r.kernel.org>
Subject: Re: [PATCH 0/3] Fix ACPI BGRT support for images located in EFI boot
 services memory

On 09/04/2012 10:59 AM, Josh Triplett wrote:
>
> Unfortunately not.  We need enough of ACPI available to go read the
> BGRT to know what to copy, so we need to defer freeing boot services
> code until after we initialize ACPI (and thus everything ACPI needs,
> which includes EFI since ACPI looks for root tables there).
>
>> I wouldn't be surprised if some implementations got really cranky if
>> we accessed boot services data after we installed a new virtual memory
>> map.
>
> Note that I've carefully accessed the boot services data *through* the
> new virtual memory map, which should work fine.
>

There are some platforms which have bugs in this area, so there are 
other reasons to defer freeing up boot memory until as late in the boot 
process as we can possibly get away with.

free_initmem() is presuambly the place that makes most sense.  This is 
EFI-specific but not x86-specific, let's not commingle those concepts, 
please...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/