Re: [PATCH 0/4] Defer 3rd party images loading to after EndOfDxe

[Laszlo Ersek <lersek@redhat.com>]

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 <ruiyu.ni@intel.com>; Gao, Liming <liming.gao@intel.com>;
>> edk2-devel@lists.01.org <edk2-devel@ml01.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 <ruiyu.ni@intel.com>; 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<mailto: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<mailto: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
>>>
>