Re: [PATCH] x86: setup: extend low identity map to cover whole kernel range

2015-10-15 Thread H. Peter Anvin
On October 14, 2015 2:39:58 PM PDT, Andy Lutomirski wrote: >On Wed, Oct 14, 2015 at 2:00 PM, Matt Fleming > wrote: >> On Wed, 14 Oct, at 09:22:03AM, Andy Lutomirski wrote: >>> On Wed, Oct 14, 2015 at 6:52 AM, Matt Fleming >

Re: [PATCH v2] x86/mm: warn on W+x mappings

2015-10-15 Thread Matt Fleming
On Wed, 14 Oct, at 05:35:22PM, Borislav Petkov wrote: > On Wed, Oct 14, 2015 at 08:30:48AM -0700, Andy Lutomirski wrote: > > Can we just unmap these things until someone tries to do an EFI call, > > and then unmap them again after the call returns? We already switch > > pgds for EFI IIRC. > >

Re: [PATCH v2] x86/mm: warn on W+x mappings

2015-10-15 Thread Borislav Petkov
On Thu, Oct 15, 2015 at 11:10:16AM +0100, Matt Fleming wrote: > We do this for the Linux UEFI Validation project kernel [1]. There, we > do not map EFI Boot Services regions by default, only if the firmware > tries to access them. > > This gives us the opporunity to print an error message if Boot

Re: [PATCH] x86: setup: extend low identity map to cover whole kernel range

2015-10-15 Thread Matt Fleming
On Wed, 14 Oct, at 02:39:58PM, Andy Lutomirski wrote: > > Trivia for your amusement: > > AFAICT it's entirely permissible for the GDTR and/or LDT descriptor to > point to unmapped memory. Any attempt to use them (segment loads, > interrupts, IRET, etc) will try to access that memory as if the

Re: [PATCH v2] x86/mm: warn on W+x mappings

2015-10-15 Thread Ricardo Neri
On Thu, 2015-10-15 at 12:33 +0200, Borislav Petkov wrote: > Yeah, that's actually a good idea. Why not upstream it for the wider > audience so that people can actually start reporting b0rked UEFIs? > With > a big and nice FW_BUG splat in there... We attempted to upstream in the past but later I

RE: CPER support for 32GiB 64GiB DIMMs

2015-10-15 Thread Luck, Tony
> Matt Fleming mentioned to me that Tony Luck recently fixed a > compatibility issue with Memory Error Record structure. > I ask, how do we want to handle the processing of a CPER > memory error record with support for larger DIMMs? I looked at this a bit when I was making the compatibility

CPER support for 32GiB 64GiB DIMMs

2015-10-15 Thread Croxon, Nigel
Hello all, Description of problem: The existing Common Platform Error Record (CPER) memory error format can't fully support 32GiB and 64GiB DIMMs. The UEFI spec has changed to use previously reserved bits in the record provide that support. Kernel processing of CPER memory error records will