Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime

From: "H. Peter Anvin" <hpa@zytor.com>
To: Andy Lutomirski <luto@amacapital.net>, Ingo Molnar <mingo@kernel.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>,
	Thomas Gleixner <tglx@linutronix.de>,
	Matt Fleming <matt.fleming@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	"Lee, Chun-Yi" <jlee@suse.com>, Borislav Petkov <bp@suse.de>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Peter Jones <pjones@redhat.com>,
	James Bottomley <JBottomley@odin.com>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Dave Young <dyoung@redhat.com>, stable <stable@vger.kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	Brian Gerst <brgerst@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime
Date: Sat, 26 Sep 2015 10:20:22 -0700	[thread overview]
Message-ID: <E40EBF14-FD9E-49C0-A7FB-951958F72F79@zytor.com> (raw)
In-Reply-To: <CALCETrUeGAedCKcSCvedyooamr6-tyfb3-b3uYDZG+k3Q_v9rw@mail.gmail.com>

I think it "works" because the affected BIOSes don't put spaces between the chunks.  I have discussed this with Matt.

On September 26, 2015 10:01:14 AM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>On Fri, Sep 25, 2015 at 10:56 PM, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> So this commit worries me.
>>
>> This bug is a good find, and the fix is obviously needed and urgent,
>but I'm not
>> sure about the implementation at all. (I've Cc:-ed a few more x86 low
>level
>> gents.)
>>
>> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
>>> +             /*
>>> +              * Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE
>>> +              * config table feature requires us to map all entries
>>> +              * in the same order as they appear in the EFI memory
>>> +              * map. That is to say, entry N must have a lower
>>> +              * virtual address than entry N+1. This is because the
>>> +              * firmware toolchain leaves relative references in
>>> +              * the code/data sections, which are split and become
>>> +              * separate EFI memory regions. Mapping things
>>> +              * out-of-order leads to the firmware accessing
>>> +              * unmapped addresses.
>>> +              *
>
>I'm clearly missing something.  What is EFI doing that it doesn't care
>how big the gap between sections is but it still requires them to be
>in order?  It's not as though x86_64 has an addressing mode that
>allows only non-negative offsets.
>
>--Andy

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.