Running pieces of PEI from binary UEFI images

Running pieces of PEI from binary UEFI images

[Stefano Cristalli]

Hello everyone,

I'm interested in experimenting with the PEI phase using EmulatorPkg,
OVMF and other EDKII parts that could be useful.
In particular, I'm interested in the possibility of integrating parts
of an existing pre-built binary UEFI image with such environments. If
the image was developed based on EDKII, would I expect things to work?
I'm not looking for complete emulation, I just think it would be
interesting to be able to single-step code inside PEIMs or even the
PeiCore from random images, leveraging the already existing EDKII
infrastructures (rather than switching to other debugging/emulation
projects).

I thought that the task might be feasible, since the layout of the
memory at the beginning of PEI and even the arguments passed to the
PeiCore are standardized... I should at least be able to begin
execution.

What do you think? Am I missing something?

Additionally, I would ask for technical help, as it's not clear to me
how exactly I would be able to load such modules. I saw that there is
the possibility of loading binaries inside an EDKII image build (cfr.
INF_Spec_1_25 section 2.7), but I don't understand how would I do this
for PEI binaries and if I could expect things to work (as in with only
the pointer to the image, without any additional information
specified).

I'd really appreciate if someone could give me some explanations to
clear my ideas about this. Some pointers to documentation would be
just fine, for it's quite complicated to figure out completely as an
EDKII beginner. "Dude, it's completely unfeasible" is also fine and
helpful as a response, if that's the case for some reason.

Thanks in advance.
Best regards.

Stefano Cristalli

Re: Running pieces of PEI from binary UEFI images

[Andrew Fish]

> On Apr 10, 2017, at 12:48 AM, Stefano Cristalli <stefanocristalli@gmail.com> wrote:
> 
> Hello everyone,
> 
> I'm interested in experimenting with the PEI phase using EmulatorPkg,
> OVMF and other EDKII parts that could be useful.
> In particular, I'm interested in the possibility of integrating parts
> of an existing pre-built binary UEFI image with such environments. If
> the image was developed based on EDKII, would I expect things to work?
> I'm not looking for complete emulation, I just think it would be
> interesting to be able to single-step code inside PEIMs or even the
> PeiCore from random images, leveraging the already existing EDKII
> infrastructures (rather than switching to other debugging/emulation
> projects).
> 
> I thought that the task might be feasible, since the layout of the
> memory at the beginning of PEI and even the arguments passed to the
> PeiCore are standardized... I should at least be able to begin
> execution.
> 
> What do you think? Am I missing something?
> 
> Additionally, I would ask for technical help, as it's not clear to me
> how exactly I would be able
> to load such modules. I saw that there is
> the possibility of loading binaries inside an EDKII image build (cfr.
> INF_Spec_1_25 section 2.7), but I don't understand how would I do this
> for PEI binaries and if I could expect things to work (as in with only
> the pointer to the image, without any additional information
> specified).
> 


Stefano,

PEI and DXE are designed to support your usage model. The FD (Flash Device) layout is a simple file system (usually read only, but does not have to be) called an FV (Firmware Volume). The FV contains files that are named by EFI_GUID (UUID), and does not support directories. Each file in an FV consists of a set of sections and sections can encapsulate other sections (that is how compression works). Two (PEI and DXE) of the section types are for depex (Dependency Expressions). The PEI depex grammar is simpler than DXE but they both support TRUE, and ANDing together PPI/Protocol GUIDs. When the depex is true  the PEI/DXE Driver is queued for dispatch. So PPI_A AND PPI_B means dispatch this PEIM when both PPI_A and PPI_B are installed in the system. The PEI and DXE Cores both contain dispatchers that make all this happen. This is all described in great detail in the UEFI Platform Initialization (PI) Specification that you can download from here: http://www.uefi.org/specifications

The edk2 uses FDF files to layout the FD and build FVs. Here is an example of a binary DXE driver that will dispatch after gPlatformGOPPolicyGuid is installed. 

https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L577

 FILE DRIVER = FF0C8745-3270-4439-B74F-3E45F8C77064 {
  SECTION DXE_DEPEX_EXP = {gPlatformGOPPolicyGuid}
  SECTION PE32 = Vlv2MiscBinariesPkg/GOP/7.2.1011/RELEASE_VS2008x86/$(DXE_ARCHITECTURE)/IntelGopDriver.efi
  SECTION UI = "IntelGopDriver"
}

The depex type would be different for PEI  but you get the idea. The FDF spec lives here: https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20Specifications

In PEI it is common that the image type may be TE vs. PE/COFF. TE (Tiano Executable) is just a hack to make the PE/COFF header smaller, as in PE/COFF (unlike other image formats) the header is part of the executable image. In general TE makes the most sense when an image is executed from FLASH. You can tell if an image is TE if you hexdump it  you will see a VZ signature, and PE/COFF has a PE/0/0 header and can also start with a DOS header that has an MZ signature.

The PEI Core  will use the FV to find the PE/COFF image, and from the PE/COFF header it can find the offset to the entry point. Thus the PEI Core can call into the PE/COFF image and run it from FLASH, or it can shadow it into memory, relocate the image, and call the entry point. 

Thanks,

Andrew Fish

PS MZ is for Mark Zbikowski one of the developers of MS-DOS. VZ is for Vincent Zimmer as he wrote that part of the Tiano Spec that ended up in the PI Spec. Vincent also made the uninitialized memory value 0xAF as a joke about my initials. 

> I'd really appreciate if someone could give me some explanations to
> clear my ideas about this. Some pointers to documentation would be
> just fine, for it's quite complicated to figure out completely as an
> EDKII beginner. "Dude, it's completely unfeasible" is also fine and
> helpful as a response, if that's the case for some reason.
> 
> Thanks in advance.
> Best regards.
> 
> Stefano Cristalli
> _______________________________________________
> edk2-devel mailing
> list
> edk2-devel@lists.01.org
> https://angler.apple.com:443/proxy?url=ChY71XmEIaglKYTvqPpJ7AsI5LDpggaDTaabgJPkJxd8IubgWIh3iPGbZH%2BpoQgRuP3YvQVwjIVArds4ikYRj%2BSF45Qc%2FowwxUMxCowjAQA%3D&rewritten=true&o=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-devel