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

2015-09-26 Thread Ard Biesheuvel
On 25 September 2015 at 22:56, Ingo Molnar 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

Re: [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

2015-09-26 Thread Ard Biesheuvel
On 25 September 2015 at 23:01, Ingo Molnar wrote: > > * Matt Fleming wrote: > >> From: Ard Biesheuvel >> >> The new Properties Table feature introduced in UEFIv2.5 may split >> memory regions that cover PE/COFF memory images

Re: [PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions

2015-09-26 Thread Ingo Molnar
* Matt Fleming wrote: > From: Ard Biesheuvel > > The new Properties Table feature introduced in UEFIv2.5 may split > memory regions that cover PE/COFF memory images into separate code > and data regions. Since these regions only differ in

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

2015-09-26 Thread Andy Lutomirski
On Fri, Sep 25, 2015 at 10:56 PM, Ingo Molnar 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

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

2015-09-26 Thread Ard Biesheuvel
On 26 September 2015 at 10:20, H. Peter Anvin wrote: > I think it "works" because the affected BIOSes don't put spaces between the > chunks. I have discussed this with Matt. > Forgive the ASCII art but perhaps an illustration might help: before the 2.5 feature, PE/COFF runtime

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

2015-09-26 Thread Matt Fleming
On Sat, 26 Sep, at 07:56:43AM, Ingo Molnar 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.) Thanks, the more the merrier. > *

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

2015-09-26 Thread Matt Fleming
On Sat, 26 Sep, at 10:20:22AM, H. Peter Anvin wrote: > > I think it "works" because the affected BIOSes don't put spaces > between the chunks. I have discussed this with Matt. Right, that's very true. Though note that the current mapping algorithm will handle a gap <= PMD_SIZE, it's just

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

2015-09-26 Thread Matt Fleming
On Sat, 26 Sep, at 12:49:26PM, H. Peter Anvin wrote: > > It is still a hack unless all relative offsets are preserved. That > is actually simpler, even: no sorting necessary. Unless I'm missing something, preserving relative offsets is exactly what we do today, modulo PMD_SIZE gaps. -- Matt

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

2015-09-26 Thread H. Peter Anvin
Sadly a lot of firmware is known to fail in that configuration :( That was very much our guest choice. I don't actually think it is all that infeasible to keep relative offsets consistent for the regions we have to map. PMD_SIZE is not a very large chunk so it could be a problem. On

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

2015-09-26 Thread H. Peter Anvin
It is still a hack unless all relative offsets are preserved. That is actually simpler, even: no sorting necessary. On September 26, 2015 11:15:57 AM PDT, Ard Biesheuvel wrote: >On 26 September 2015 at 10:20, H. Peter Anvin wrote: >> I think it