Re: Question About DxeDriver load process

[Andrew Fish <afish@apple.com>]

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