* Question About DxeDriver load process @ 2018-07-27 18:12 Rafael Machado 2018-07-27 22:14 ` Andrew Fish 0 siblings, 1 reply; 5+ messages in thread From: Rafael Machado @ 2018-07-27 18:12 UTC (permalink / raw) To: edk2-devel@lists.01.org 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Question About DxeDriver load process 2018-07-27 18:12 Question About DxeDriver load process Rafael Machado @ 2018-07-27 22:14 ` Andrew Fish 2018-07-30 11:46 ` Rafael Machado 0 siblings, 1 reply; 5+ messages in thread From: Andrew Fish @ 2018-07-27 22:14 UTC (permalink / raw) To: Rafael Machado; +Cc: edk2-devel@lists.01.org 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Question About DxeDriver load process 2018-07-27 22:14 ` Andrew Fish @ 2018-07-30 11:46 ` Rafael Machado 2018-07-30 15:28 ` Andrew Fish 0 siblings, 1 reply; 5+ messages in thread From: Rafael Machado @ 2018-07-30 11:46 UTC (permalink / raw) To: Andrew Fish; +Cc: edk2-devel@lists.01.org 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 > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Question About DxeDriver load process 2018-07-30 11:46 ` Rafael Machado @ 2018-07-30 15:28 ` Andrew Fish 2018-07-31 0:43 ` Rafael Machado 0 siblings, 1 reply; 5+ messages in thread From: Andrew Fish @ 2018-07-30 15:28 UTC (permalink / raw) To: Rafael Machado; +Cc: edk2-devel@lists.01.org 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Question About DxeDriver load process 2018-07-30 15:28 ` Andrew Fish @ 2018-07-31 0:43 ` Rafael Machado 0 siblings, 0 replies; 5+ messages in thread From: Rafael Machado @ 2018-07-31 0:43 UTC (permalink / raw) To: Andrew Fish; +Cc: edk2-devel@lists.01.org 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 > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-07-31 0:43 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-07-27 18:12 Question About DxeDriver load process Rafael Machado 2018-07-27 22:14 ` Andrew Fish 2018-07-30 11:46 ` Rafael Machado 2018-07-30 15:28 ` Andrew Fish 2018-07-31 0:43 ` Rafael Machado
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox