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
>
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.
>
>
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
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
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
> 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
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