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

2015-10-01 Thread Ingo Molnar
* H. Peter Anvin wrote: > On 09/27/2015 12:06 AM, Ingo Molnar wrote: > > > > * Ard Biesheuvel wrote: > > > >>> If we allocate the EFI runtime as a single virtual memory block then > >>> issues > >>> like rounding between sections does not even come up as a problem: we map > >>> the > >>>

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

2015-10-01 Thread Ingo Molnar
* H. Peter Anvin wrote: > On 09/27/2015 12:06 AM, Ingo Molnar wrote: > > > > * Ard Biesheuvel wrote: > > > >>> If we allocate the EFI runtime as a single virtual memory block then > >>> issues > >>> like rounding between sections does not even

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

2015-09-30 Thread Borislav Petkov
On Tue, Sep 29, 2015 at 05:56:07PM -0700, H. Peter Anvin wrote: > On 09/29/2015 07:36 AM, Matt Fleming wrote: > > > > That's a pretty good summary for x86. I think specifically the reason > > we map the EFI memmap entries "backwards" (entry N has higher VA than > > entry N+1) is because the code

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

2015-09-30 Thread Borislav Petkov
On Tue, Sep 29, 2015 at 05:56:07PM -0700, H. Peter Anvin wrote: > On 09/29/2015 07:36 AM, Matt Fleming wrote: > > > > That's a pretty good summary for x86. I think specifically the reason > > we map the EFI memmap entries "backwards" (entry N has higher VA than > > entry N+1) is because the code

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

2015-09-29 Thread Ard Biesheuvel
On 30 September 2015 at 03:16, Andy Lutomirski wrote: > On Tue, Sep 29, 2015 at 6:03 PM, H. Peter Anvin wrote: >> On 09/27/2015 12:06 AM, Ingo Molnar wrote: >>> >>> * Ard Biesheuvel wrote: >>> > If we allocate the EFI runtime as a single virtual memory block then > issues > like

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

2015-09-29 Thread H. Peter Anvin
On 09/29/2015 06:16 PM, Andy Lutomirski wrote: > > Can we at least do 1:1 without an offset on arm64? Given that Linux > seems to be more of a reference on arm64 than Windows is, maybe that > would give everyone something vaguely sane to work with. > I have no idea. That's a question for the

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

2015-09-29 Thread Andy Lutomirski
On Tue, Sep 29, 2015 at 6:03 PM, H. Peter Anvin wrote: > On 09/27/2015 12:06 AM, Ingo Molnar wrote: >> >> * Ard Biesheuvel wrote: >> If we allocate the EFI runtime as a single virtual memory block then issues like rounding between sections does not even come up as a problem: we map

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

2015-09-29 Thread H. Peter Anvin
On 09/27/2015 12:06 AM, Ingo Molnar wrote: > > * Ard Biesheuvel wrote: > >>> If we allocate the EFI runtime as a single virtual memory block then issues >>> like rounding between sections does not even come up as a problem: we map >>> the >>> original offsets and sizes byte by byte. >> >>

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

2015-09-29 Thread H. Peter Anvin
On 09/29/2015 07:36 AM, Matt Fleming wrote: > > That's a pretty good summary for x86. I think specifically the reason > we map the EFI memmap entries "backwards" (entry N has higher VA than > entry N+1) is because the code was easier to write that way, but > you'll know better than me ;-) >

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

2015-09-29 Thread Matt Fleming
On Sun, 27 Sep, at 12:40:14PM, Borislav Petkov wrote: > On Sun, Sep 27, 2015 at 09:06:44AM +0200, Ingo Molnar wrote: > > Could we please re-list all the arguments pro and contra of 1:1 physical > > mappings, > > in a post that also explains the background so that more people can chime > > in,

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

2015-09-29 Thread Borislav Petkov
On Tue, Sep 29, 2015 at 05:31:00PM +0800, Dave Young wrote: > http://permalink.gmane.org/gmane.linux.kernel.efi/822 > > And more replies here: > http://comments.gmane.org/gmane.linux.kernel.efi/820 Whatever we did think back then, it all is moot as long as some UEFI vendors do funky crap or the

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

2015-09-29 Thread Dave Young
On 09/27/15 at 12:40pm, Borislav Petkov wrote: > On Sun, Sep 27, 2015 at 09:06:44AM +0200, Ingo Molnar wrote: > > Could we please re-list all the arguments pro and contra of 1:1 physical > > mappings, > > in a post that also explains the background so that more people can chime > > in, not > >

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

2015-09-29 Thread Dave Young
On 09/27/15 at 12:40pm, Borislav Petkov wrote: > On Sun, Sep 27, 2015 at 09:06:44AM +0200, Ingo Molnar wrote: > > Could we please re-list all the arguments pro and contra of 1:1 physical > > mappings, > > in a post that also explains the background so that more people can chime > > in, not > >

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

2015-09-29 Thread Borislav Petkov
On Tue, Sep 29, 2015 at 05:31:00PM +0800, Dave Young wrote: > http://permalink.gmane.org/gmane.linux.kernel.efi/822 > > And more replies here: > http://comments.gmane.org/gmane.linux.kernel.efi/820 Whatever we did think back then, it all is moot as long as some UEFI vendors do funky crap or the

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

2015-09-29 Thread Matt Fleming
On Sun, 27 Sep, at 12:40:14PM, Borislav Petkov wrote: > On Sun, Sep 27, 2015 at 09:06:44AM +0200, Ingo Molnar wrote: > > Could we please re-list all the arguments pro and contra of 1:1 physical > > mappings, > > in a post that also explains the background so that more people can chime > > in,

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

2015-09-29 Thread Andy Lutomirski
On Tue, Sep 29, 2015 at 6:03 PM, H. Peter Anvin wrote: > On 09/27/2015 12:06 AM, Ingo Molnar wrote: >> >> * Ard Biesheuvel wrote: >> If we allocate the EFI runtime as a single virtual memory block then issues like rounding between sections

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

2015-09-29 Thread H. Peter Anvin
On 09/29/2015 07:36 AM, Matt Fleming wrote: > > That's a pretty good summary for x86. I think specifically the reason > we map the EFI memmap entries "backwards" (entry N has higher VA than > entry N+1) is because the code was easier to write that way, but > you'll know better than me ;-) >

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

2015-09-29 Thread H. Peter Anvin
On 09/29/2015 06:16 PM, Andy Lutomirski wrote: > > Can we at least do 1:1 without an offset on arm64? Given that Linux > seems to be more of a reference on arm64 than Windows is, maybe that > would give everyone something vaguely sane to work with. > I have no idea. That's a question for the

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

2015-09-29 Thread H. Peter Anvin
On 09/27/2015 12:06 AM, Ingo Molnar wrote: > > * Ard Biesheuvel wrote: > >>> If we allocate the EFI runtime as a single virtual memory block then issues >>> like rounding between sections does not even come up as a problem: we map >>> the >>> original offsets and

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

2015-09-29 Thread Ard Biesheuvel
On 30 September 2015 at 03:16, Andy Lutomirski wrote: > On Tue, Sep 29, 2015 at 6:03 PM, H. Peter Anvin wrote: >> On 09/27/2015 12:06 AM, Ingo Molnar wrote: >>> >>> * Ard Biesheuvel wrote: >>> > If we allocate the EFI runtime

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

2015-09-28 Thread Ingo Molnar
* Borislav Petkov wrote: > On Sun, Sep 27, 2015 at 09:06:44AM +0200, Ingo Molnar wrote: > > > Could we please re-list all the arguments pro and contra of 1:1 physical > > mappings, in a post that also explains the background so that more people > > can > > chime in, not just people versed in

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

2015-09-28 Thread Ingo Molnar
* Borislav Petkov wrote: > On Sun, Sep 27, 2015 at 09:06:44AM +0200, Ingo Molnar wrote: > > > Could we please re-list all the arguments pro and contra of 1:1 physical > > mappings, in a post that also explains the background so that more people > > can > > chime in, not just

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

2015-09-27 Thread Borislav Petkov
On Sun, Sep 27, 2015 at 09:06:44AM +0200, Ingo Molnar wrote: > Could we please re-list all the arguments pro and contra of 1:1 physical > mappings, > in a post that also explains the background so that more people can chime in, > not > just people versed in EFI internals? It's very much

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

2015-09-27 Thread Ingo Molnar
* Ard Biesheuvel wrote: > > If we allocate the EFI runtime as a single virtual memory block then issues > > like rounding between sections does not even come up as a problem: we map > > the > > original offsets and sizes byte by byte. > > Well, by that reasoning, we should not call

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

2015-09-27 Thread Ingo Molnar
* Ard Biesheuvel wrote: > > If we allocate the EFI runtime as a single virtual memory block then issues > > like rounding between sections does not even come up as a problem: we map > > the > > original offsets and sizes byte by byte. > > Well, by that reasoning,

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

2015-09-27 Thread Borislav Petkov
On Sun, Sep 27, 2015 at 09:06:44AM +0200, Ingo Molnar wrote: > Could we please re-list all the arguments pro and contra of 1:1 physical > mappings, > in a post that also explains the background so that more people can chime in, > not > just people versed in EFI internals? It's very much

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 into separate code >> and data regions. Since these regions only

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 the type (runtime > code vs runtime data) and the

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

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

2015-09-25 Thread Matt Fleming
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 the type (runtime code vs runtime data) and the permission bits, but not in the memory

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

2015-09-25 Thread Matt Fleming
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 the type (runtime code vs runtime data) and the permission