Re: Question About DxeDriver load process

[Rafael Machado <rafaelrodrigues.machado@gmail.com>]

Andrew,

Thanks for clarifying this!

Rafael

Em seg, 30 de jul de 2018 12:28, Andrew Fish <afish@apple.com> escreveu:

> Rafael,
>
> I forgot to mention that the DXE Core is loaded by the DXE IPL PEIM. This
> can sometime require the discovery of a new FV to find the DXE Core.
>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c#L254
>
> Thanks,
>
> Andrew Fish
>
> > On Jul 30, 2018, at 4:46 AM, Rafael Machado <
> rafaelrodrigues.machado@gmail.com> wrote:
> >
> > Hi Andrew
> >
> > Thanks a lot for the perfectly detailed explanation!
> > Amazing!
> >
> > Thanks and Regards
> > Rafael R. Machado
> >
> > Em sex, 27 de jul de 2018 às 19:14, Andrew Fish <afish@apple.com>
> escreveu:
> >
> >> Rafael,
> >>
> >> Since it is useful to also understand this when you are bringing up a
> >> platform....
> >>
> >> SEC generally contains the hardware reset vector. SEC hands off to the
> PEI
> >> Core. Generally there is some build magic to help SEC find the PEI Core.
> >> Worst case you can walk the BFV (Boot Firmware Volume) and find it.
> >>
> >> SEC hands the PEI Core the EFI_SEC_PEI_HAND_OFF structure. This is how
> the
> >> PEI Core knows about stack, heap, and the location of the BFV to find
> PEIMs
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiPeiCis.h#L967
> >>
> >> The PEI Core has a PPI Notify Callback for
> >> gEfiPeiFirmwareVolumeInfoPpiGuid, and
> gEfiPeiFirmwareVolumeInfo2PpiGuid to
> >> discover new FVs.
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/FwVol/FwVol.c#L547
> >>
> >> PEI Code writes hobs, EFI_HOB_TYPE_FV and EFI_HOB_TYPE_FV3, to help DXE
> >> discover FVs.
> >>
> >> When the DXE Core is started it will call FwVolBlockDriverInit() and
> all
> >> the EFI_HOB_TYPE_FV, and optionally pick up the authentication status
> from
> >> EFI_HOB_TYPE_FV3, will get processed.
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c#L625
> >>
> >> via calling ProduceFVBProtocolOnBuffer(). ProduceFVBProtocolOnBuffer()
> can
> >> also be called gBS->ProcessFirmwareVolume().
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c#L452
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c#L687
> >>
> >> Loading drivers from the FV is the job of the DXE Dispatcher. The DXE
> >> Dispatcher has protocol notify event on gEfiFirmwareVolume2ProtocolGuid
> >> that will get the executables in the Dispatch list, mDiscoveredList.
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c#L1193
> >>
> >> So adding a gEfiFirmwareVolume2ProtocolGuid driver, or calling
> >> gBS->ProcessFirmwareVolume() is how you would make an FV show up that
> was
> >> not listed in the HOBs.
> >>
> >> In the DXE Phase security is handle by gBS->LoadImage() and it uses
> >> gEfiSecurity2ArchProtocolGuid and gEfiSecurityArchProtocolGuid to
> validate
> >> the image. This makes sense as a signed EFI PE/COFF image has the
> signature
> >> in the PE/COFF image, so you have to start the PE/COFF loading process
> to
> >> verify that signature.  gEfiSecurity2ArchProtocolGuid lets you build
> >> security policy based on the location of the driver.
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Image/Image.c#L1041
> >>
> >> When the Dispatcher runs of things to Dispatch it returns and the DXE
> Core
> >> calls the BDS to process platform Boot Device Selection.
> >>
> >>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c#L550
> >>
> >> After BDS starts the only way to run code from an FV would be to call
> >> gDS->Dispatcher(). Likely you would call gDS->ProcessFirmwareVolume()
> and
> >> then  gDS->Dispatcher(). To speed boot it is not uncommon to have
> multiple
> >> FVs. For example you could have an FV that contained all the setup
> >> resources and only call gDS->ProcessFirmwareVolume() on that FV if the
> user
> >> hit the Setup hot key.
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >> PS For x86 (0xFFFFFFF0 reset vector) and any other architectures that
> have
> >> the reset vector at the end there is a special file name in the FV
> called
> >> gEfiFirmwareVolumeTopFileGuid that tells the FV creation tools to put
> that
> >> file at the very end of the FV, so the end of that file would end up at
> the
> >> reset vector location.
> >>
> >>
> >>> On Jul 27, 2018, at 11:12 AM, Rafael Machado <
> >> rafaelrodrigues.machado@gmail.com> wrote:
> >>>
> >>> Hi everyone
> >>>
> >>> I have a question.
> >>> Let's suppose I have a BIOS with several FV regions. Between these FV
> >> there
> >>> is one that is empty.
> >>>
> >>> My question is:
> >>> In case I get this BIOS and inject a dxe driver at this FV. Would it be
> >>> executed, or there are specific FVs that are considered as containers
> to
> >>> executable code avoiding other FVs content to be executed?
> >>>
> >>> In case the answer comes with some code examples from edk2 tree it
> would
> >> be
> >>> amazing :)
> >>>
> >>> Thanks and Regards
> >>> Rafael
> >>> _______________________________________________
> >>> 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
>
>