From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CBC3481DBC for ; Mon, 7 Nov 2016 06:03:42 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 44FBD6198B; Mon, 7 Nov 2016 14:03:45 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-129.phx2.redhat.com [10.3.116.129]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA7E3hAG017263; Mon, 7 Nov 2016 09:03:43 -0500 To: "Ni, Ruiyu" References: <20161104005942.345832-1-ruiyu.ni@intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14B49EAAD@shsmsx102.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D58E51C31@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D58E56748@SHSMSX104.ccr.corp.intel.com> Cc: "Gao, Liming" , "edk2-devel@lists.01.org" , Ard Biesheuvel , "Jordan Justen (Intel address)" From: Laszlo Ersek Message-ID: <1734fa13-27ac-6653-279c-7bb6cfb021e1@redhat.com> Date: Mon, 7 Nov 2016 15:03:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D58E56748@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 07 Nov 2016 14:03:45 +0000 (UTC) Subject: Re: [PATCH 0/4] Defer 3rd party images loading to after EndOfDxe X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 14:03:42 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 11/07/16 03:32, Ni, Ruiyu wrote: > > > Thanks/Ray > >> -----Original Message----- >> From: Laszlo Ersek [mailto:lersek@redhat.com] >> Sent: Saturday, November 5, 2016 12:48 AM >> To: Ni, Ruiyu ; Gao, Liming ; >> edk2-devel@lists.01.org >> Subject: Re: [edk2] [PATCH 0/4] Defer 3rd party images loading to after >> EndOfDxe >> >> On 11/04/16 07:09, Ni, Ruiyu wrote: >>> No. >>> The open source platform patch will be sent out later. >> >> What are the deferred / 3rd party images? Do Driver#### and SysPrep#### >> qualify? > > The images which are not from FV are treated as 3rd party images. And they will be > deferred to dispatch when they are dispatched before EndOfDxe event. > It's a new feature in the BS.LoadImage() path which can disallow executing > 3rd party images before EndOfDxe and re-execute them after EndOfDxe. Thank you for the explanation. OvmfPkg's and ArmVirtPkg's PlatformBootManagerLib instances signal EndOfDxe in BeforeConsole(). BdsDxe executes the Driver#### options between BeforeConsole() and AfterConsole(), so the new deferral feature should not incur observable changes for OvmfPkg's and ArmVirtPkg's Driver#### handling -- by the time a Driver is loaded from (say) the ESP, EndOfDxe will have been signaled anyway. Also, TryRunningQemuKernel() is called on both platforms from AfterConsole(). This is esp. relevant for ArmVirtPkg, which uses LoadImage() to load the kernel (from a synthetic file system). Given that this again occurs after EndOfDxe (which is signaled in BeforeConsole), it should continue working fine. You mentioned that a new PlatformBootManagerLib API -- EfiBootManagerDispatchDeferredImages() -- will be introduced for running the deferred images after EndOfDxe, and that the Platform BDS code will be responsible for calling that API. For ArmVirtPkg and OvmfPkg, this API seems to be a no-op at the moment, but I agree that for completeness we should call them. (Although, the fallback added in patch #3 would also handle them.) I propose that in ArmVirtPkg, we call the new API right after signaling EndOfDxe. In OvmfPkg, we should call the new API after installing gEfiDxeSmmReadyToLockProtocolGuid. (The relevance of gEfiDxeSmmReadyToLockProtocolGuid is discussed in your patch #4 as well.) I'll comment on patch #4 separately too. Thank you, Laszlo >> Or, is this related to value 3 ("Defer execution when there is security >> violation") of: >> - PcdOptionRomImageVerificationPolicy, >> - PcdRemovableMediaImageVerificationPolicy, >> - PcdFixedMediaImageVerificationPolicy? > > No. > >> >> Is the deferral documented somewhere in the UEFI spec, or do we have a >> Mantis ticket / ECR about it? > No. > >> >> Can we improve the commit messages please? From them, I have no idea >> how the deferral is supposed to work. (I.e., what the agents are, and how >> they interact.) > Yes. I will embed my first paragraph of reply in the commit message. > >> >> Thanks >> Laszlo >> >>> From: Gao, Liming >>> Sent: Friday, November 4, 2016 1:14 PM >>> To: Ni, Ruiyu ; edk2-devel@lists.01.org >>> Subject: RE: [edk2] [PATCH 0/4] Defer 3rd party images loading to >>> after EndOfDxe >>> >>> Ray: >>> Seemly, PlatformBdsLib library instance should call >> EfiBootManagerDispatchDeferredImages(), right? Are there patches to >> update PlatformBdsLib library instance? >>> >>> Thanks >>> Liming >>>> -----Original Message----- >>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf >>>> Of Ruiyu Ni >>>> Sent: Friday, November 04, 2016 9:00 AM >>>> To: edk2-devel@lists.01.org >>>> Subject: [edk2] [PATCH 0/4] Defer 3rd party images loading to after >>>> EndOfDxe >>>> >>>> The patches change the default image loading policy by deferring 3rd >>>> party images loading to after EndOfDxe and add a new BDS API to >>>> dispatch the deferred images. >>>> >>>> Platform needs to call the new BDS API >>>> EfiBootManagerDispatchDeferredImages after EndOfDxe to ensure that >>>> any deferred images are loaded. >>>> >>>> Ruiyu Ni (4): >>>> MdeModulePkg/SecurityStubDxe: Defer 3rd party image before >> EndOfDxe >>>> MdeModulePkg/UefiBootManager: Add >>>> EfiBootManagerDispatchDeferredImages >>>> MdeModulePkg/BdsDxe: Check deferred images before booting to OS >>>> MdeModulePkg/SecurityStubDxe: Report failure if image is load >>>> earlier >>>> >>>> MdeModulePkg/Include/Library/UefiBootManagerLib.h | 13 + >>>> MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 113 ++++++ >>>> .../Library/UefiBootManagerLib/InternalBm.h | 1 + >>>> .../UefiBootManagerLib/UefiBootManagerLib.inf | 1 + >>>> MdeModulePkg/Universal/BdsDxe/Bds.h | 4 +- >>>> MdeModulePkg/Universal/BdsDxe/BdsDxe.inf | 2 + >>>> MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 89 +++++ >>>> .../SecurityStubDxe/Defer3rdPartyImageLoad.c | 413 >>>> +++++++++++++++++++++ >>>> .../SecurityStubDxe/Defer3rdPartyImageLoad.h | 95 +++++ >>>> .../Universal/SecurityStubDxe/SecurityStub.c | 14 +- >>>> .../Universal/SecurityStubDxe/SecurityStubDxe.inf | 11 +- >>>> 11 files changed, 753 insertions(+), 3 deletions(-) create mode >>>> 100644 >>>> MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c >>>> create mode 100644 >>>> MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.h >>>> >>>> -- >>>> 2.9.0.windows.1 >>>> >>>> _______________________________________________ >>>> edk2-devel mailing list >>>> edk2-devel@lists.01.org >>>> https://lists.01.org/mailman/listinfo/edk2-devel >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >