Question About DxeDriver load process

Question About DxeDriver load process

[Rafael Machado]

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

Re: Question About DxeDriver load process

[Andrew Fish]

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

Re: Question About DxeDriver load process

[Rafael Machado]

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
>
>

Re: Question About DxeDriver load process

[Andrew Fish]

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

Re: Question About DxeDriver load process

[Rafael Machado]

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
>
>