From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757465Ab3HGUTS (ORCPT ); Wed, 7 Aug 2013 16:19:18 -0400 Received: from arkanian.console-pimps.org ([212.110.184.194]:43185 "EHLO arkanian.console-pimps.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756335Ab3HGUTR (ORCPT ); Wed, 7 Aug 2013 16:19:17 -0400 Date: Wed, 7 Aug 2013 21:19:08 +0100 From: Matt Fleming To: Andrew Fish Cc: edk2-devel@lists.sourceforge.net, Laszlo Ersek , linux-efi@vger.kernel.org, Gleb Natapov , lkml , David Woodhouse Subject: Re: [edk2] Corrupted EFI region Message-ID: <20130807201908.GG2515@console-pimps.org> References: <51FFC19A.1020204@redhat.com> <20130805161247.GF31845@pd.tnic> <51FFD5B0.9080000@redhat.com> <20130805164731.GG31845@pd.tnic> <52001896.1030509@redhat.com> <20130805220808.GC14067@pd.tnic> <20130806141036.GD14891@pd.tnic> <520116D1.2010000@redhat.com> <20130807151935.GJ17920@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ Readding Matthew Garrett to the Cc list, seeing as we both got removed for some unknown reason ] On Wed, 07 Aug, at 10:23:56AM, Andrew Fish wrote: > OK so I think I need some Cliff Notes here to help me understand what > is going on... > > type 4 is EfiBootServicesData and attr 0x0f is cache attributes with > no request for a runtime mapping. This is not runtime memory so to the > OS loader it is just memory EFI has used that will get freed back to > the OS after ExitBootServices(), along with EfiBootServicesCode, > EfiLoaderCode, and EfiLoaderData. The EfiLoaderCode and EfiLoaderData > also get freed back to the OS and they just exist for the convenience > of the OS loader. > > So I can't figure out why this maters? Given: We've seen a bunch of systems that make calls into EfiBootServicesCode after ExitBootServices(). There were some Apple machines in that list, though I don't have the details but Matthew should. So we map these regions unconditionally and in their original state, otherwise the firmware will generate fatal page faults when trying to access those memory regions. -- Matt Fleming, Intel Open Source Technology Center From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Fleming Subject: Re: [edk2] Corrupted EFI region Date: Wed, 7 Aug 2013 21:19:08 +0100 Message-ID: <20130807201908.GG2515@console-pimps.org> References: <51FFC19A.1020204@redhat.com> <20130805161247.GF31845@pd.tnic> <51FFD5B0.9080000@redhat.com> <20130805164731.GG31845@pd.tnic> <52001896.1030509@redhat.com> <20130805220808.GC14067@pd.tnic> <20130806141036.GD14891@pd.tnic> <520116D1.2010000@redhat.com> <20130807151935.GJ17920@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andrew Fish Cc: edk2-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Laszlo Ersek , linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Gleb Natapov , lkml , David Woodhouse List-Id: linux-efi@vger.kernel.org [ Readding Matthew Garrett to the Cc list, seeing as we both got removed for some unknown reason ] On Wed, 07 Aug, at 10:23:56AM, Andrew Fish wrote: > OK so I think I need some Cliff Notes here to help me understand what > is going on... > > type 4 is EfiBootServicesData and attr 0x0f is cache attributes with > no request for a runtime mapping. This is not runtime memory so to the > OS loader it is just memory EFI has used that will get freed back to > the OS after ExitBootServices(), along with EfiBootServicesCode, > EfiLoaderCode, and EfiLoaderData. The EfiLoaderCode and EfiLoaderData > also get freed back to the OS and they just exist for the convenience > of the OS loader. > > So I can't figure out why this maters? Given: We've seen a bunch of systems that make calls into EfiBootServicesCode after ExitBootServices(). There were some Apple machines in that list, though I don't have the details but Matthew should. So we map these regions unconditionally and in their original state, otherwise the firmware will generate fatal page faults when trying to access those memory regions. -- Matt Fleming, Intel Open Source Technology Center