Sec and Reset vector

Sec and Reset vector

[Rafael Machado]

Hi eveyrone

I'm doing some studies on edk2 and coreboot, but I'm having some questions
that I believe you can help.

On the journey to try to understand things since the beginning, so they
make sense in future, I'm trying to understand how does the Initial phases
of UEFI  / PI firmware work. To do that I got a bios image and start to
reverse it to check the modules and everything present at that bios. Now I
understand, at least the basics, about DXE and PEI phase.

The main question that I have now is about the SEC phase.
To try to understand the SEC phase I tried to reverse this firmware so I
could check the reset vector's first jump or something like that.
The surprise I have is that I was not able to find this code.

To be sure I was reversing on the correct way I generated a coreboot image.
On the image below we can see the initial code of a firmware generated
using coreboot

[image: pasted1]

But at the UEFI firmware I'm studying I'm not able to find anything similar
to that.
My guess before starting this was that at least the SEC initial code should
be similar to the legacy way of doing things, a jmp at 0xfff:fff0
and after that the magic should get started with all uefi phases.

Could someone please give me some light on that?


Thanks and Regards
Rafael R. Machado

Re: Sec and Reset vector

[Marvin H?user]

Hey Rafael,

There actually is some generic SEC code in UefiCpuPkg you might want to take a look at. It's generic because it does not have "Intel NDA" code, such as CAR (Cache-As-RAM) etc.
The Reset Vector may or may not be part of SecCore. It's either embedded within the SecCore module, or a separate file in the FFS. You can check the start/end address of the modules (e.g. with UEFITool) and find the Reset Vector file that way.

PS.: Seems like inline images are not supported by the mailing list (or is it my error?). Either way, I do not see the image in my mail client (Outlook 2016).

Regards,
Marvin.

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Rafael Machado
> Sent: Saturday, October 22, 2016 6:28 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Sec and Reset vector
> 
> Hi eveyrone
> 
> I'm doing some studies on edk2 and coreboot, but I'm having some questions
> that I believe you can help.
> 
> On the journey to try to understand things since the beginning, so they make
> sense in future, I'm trying to understand how does the Initial phases of UEFI
> / PI firmware work. To do that I got a bios image and start to reverse it to
> check the modules and everything present at that bios. Now I understand, at
> least the basics, about DXE and PEI phase.
> 
> The main question that I have now is about the SEC phase.
> To try to understand the SEC phase I tried to reverse this firmware so I could
> check the reset vector's first jump or something like that.
> The surprise I have is that I was not able to find this code.
> 
> To be sure I was reversing on the correct way I generated a coreboot image.
> On the image below we can see the initial code of a firmware generated
> using coreboot
> 
> [image: pasted1]
> 
> But at the UEFI firmware I'm studying I'm not able to find anything similar to
> that.
> My guess before starting this was that at least the SEC initial code should be
> similar to the legacy way of doing things, a jmp at 0xfff:fff0 and after that the
> magic should get started with all uefi phases.
> 
> Could someone please give me some light on that?
> 
> 
> Thanks and Regards
> Rafael R. Machado
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: Sec and Reset vector

[Andrew Fish]

> On Oct 22, 2016, at 10:03 AM, Marvin H?user <Marvin.Haeuser@outlook.com> wrote:
> 
> Hey Rafael,
> 
> There actually is some generic SEC code in UefiCpuPkg you might want to take a look at. It's generic because it does not have "Intel NDA" code, such as CAR (Cache-As-RAM) etc.
> The Reset Vector may or may not be part of SecCore. It's either embedded within the SecCore module, or a separate file in the FFS. You can check the start/end address of the modules (e.g. with UEFITool) and find the Reset Vector file that way.
> 

Rafael,

There is some strange construction things going on with the SEC for X86. 

If you look in the FDF file you will see that the SEC is a PE/COFF (or TE) image and a raw binary for the 16-bit real mode reset vector code. 

https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L876 <https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L876>
[Rule.Common.SEC]
  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
    PE32  PE32    Align = 8       $(INF_OUTPUT)/$(MODULE_NAME).efi
    RAW BIN       Align = 16      |.com
  }

The .com files are constructed from *.nasmb, *.asm16, or *.S16 files. 
https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32 <https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32>

Special extensions are needed to have special build rules. The build rules are here:
https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template#L480 <https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template#L480>
Look at the [Masm16-Code-File] and [Nasm-to-Binary-Code-File] rules.

The build tools also do some magic to stitch the .com and PE/COFF (TE) file together. 
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb#L46 <https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb#L46>
;
; Pointer to the entry point of the PEI core
; It is located at 0xFFFFFFE0, and is fixed up by some build tool
; So if the value 8..1 appears in the final FD image, tool failure occurs.
;
PeiCoreEntryPoint:       DD      87654321h


The reason you need special build rules is it is really hard to get code at the end of a PE/COFF file, so you need a stripped binary for the reset vector. 

The next problem is how do you get the FV File to be at the end of the FV (that is usually free space). The PI spec defines that if an FFS file has the File GUID of gEfiFirmwareVolumeTopFileGuid then it gets place at the end of the FV. Thus the X86 SEC must have this file guid. This also triggers the magic behavior to stitch the .com and PE/COFF together. 
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.inf#L25 <https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.inf#L25>
  FILE_GUID                      = 1BA0062E-C779-4582-8566-336AE8F78F09



For ARM things are much simpler. The FV reserves 16-bytes at the start of the volume for the reset vector. If the build tools see an FV has an ARM SEC it can patch in a branch to the SEC PE/COFF (TE) entry point (going from memory hopefully I did not botch that).

https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L110 <https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L110>
  ///
  /// The first 16 bytes are reserved to allow for the reset vector of
  /// processors whose reset vector is at address 0.
  ///
  UINT8                     ZeroVector[16];



> PS.: Seems like inline images are not supported by the mailing list (or is it my error?). Either way, I do not see the image in my mail client (Outlook 2016).
> 

I don't see the image in my macOS Mail client. 

Thanks,

Andrew Fish


> Regards,
> Marvin.
> 
>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>> Rafael Machado
>> Sent: Saturday, October 22, 2016 6:28 PM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] Sec and Reset vector
>> 
>> Hi eveyrone
>> 
>> I'm doing some studies on edk2 and coreboot, but I'm having some questions
>> that I believe you can help.
>> 
>> On the journey to try to understand things since the beginning, so they make
>> sense in future, I'm trying to understand how does the Initial phases of UEFI
>> / PI firmware work. To do that I got a bios image and start to reverse it to
>> check the modules and everything present at that bios. Now I understand, at
>> least the basics, about DXE and PEI phase.
>> 
>> The main question that I have now is about the SEC phase.
>> To try to understand the SEC phase I tried to reverse this firmware so I could
>> check the reset vector's first jump or something like that.
>> The surprise I have is that I was not able to find this code.
>> 
>> To be sure I was reversing on the correct way I generated a coreboot image.
>> On the image below we can see the initial code of a firmware generated
>> using coreboot
>> 
>> [image: pasted1]
>> 
>> But at the UEFI firmware I'm studying I'm not able to find anything similar to
>> that.
>> My guess before starting this was that at least the SEC initial code should be
>> similar to the legacy way of doing things, a jmp at 0xfff:fff0 and after that the
>> magic should get started with all uefi phases.
>> 
>> Could someone please give me some light on that?
>> 
>> 
>> Thanks and Regards
>> Rafael R. Machado
>> _______________________________________________
>> 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: Sec and Reset vector

[Rafael Machado]

Hi everyone

Thanks Andrew and Marvin for the clarification.
Now things start to make sense.

But I was still not able to understand were things start on a real binary
On the attached image ResetVectorCoreboot.png we have the entry point on a
coreboot image.
What I would like to do is to find something similar to this on a UEFI Bios
image.

Based on Marvin's idea, I got the UEFI Tool and star to check the image I
have.
On the attached image TopFileInfo.png we can see to Top File mentioned by
Andrew.
The details about the Top File are these:

  Offset: FF8018h

  File GUID: 1BA0062E-C779-4582-8566-336AE8F78F09

  Type: 03h

  Attributes: 08h

  Full size: 7FE8h (32744)

  Header size: 18h (24)

  Body size: 7FD0h (32720)

  Tail size: 0h (0)

  State: F8h

  Header checksum: 99h, valid

  Data checksum: AAh, valid

  Header memory address: FFFF8018h

  Data memory address: FFFF8030h

  Compressed: No

  Fixed: No


I tried to find something similar to what I see at the coreboot image, but
didn't find anything. Neither on the PE Image section, not on the Raw image
sections.


Any idea about how could I find the entry point of sec in this case?

Thanks and Regards
Rafael R. Machado


Em sáb, 22 de out de 2016 às 16:19, Andrew Fish <afish@apple.com> escreveu:

> On Oct 22, 2016, at 10:03 AM, Marvin H?user <Marvin.Haeuser@outlook.com>
> wrote:
>
> Hey Rafael,
>
> There actually is some generic SEC code in UefiCpuPkg you might want to
> take a look at. It's generic because it does not have "Intel NDA" code,
> such as CAR (Cache-As-RAM) etc.
> The Reset Vector may or may not be part of SecCore. It's either embedded
> within the SecCore module, or a separate file in the FFS. You can check the
> start/end address of the modules (e.g. with UEFITool) and find the Reset
> Vector file that way.
>
>
> Rafael,
>
> There is some strange construction things going on with the SEC for X86.
>
> If you look in the FDF file you will see that the SEC is a PE/COFF (or TE)
> image and a raw binary for the 16-bit real mode reset vector code.
>
>
> https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L876
> [Rule.Common.SEC]
> FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
> PE32 PE32 Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
> RAW BIN Align = 16 |.com
> }
>
> The .com files are constructed from *.nasmb, *.asm16, or *.S16 files.
> https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32
>
> Special extensions are needed to have special build rules. The build rules
> are here:
>
> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template#L480
> Look at the [Masm16-Code-File] and [Nasm-to-Binary-Code-File] rules.
>
> The build tools also do some magic to stitch the .com and PE/COFF (TE)
> file together.
>
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb#L46
> ;
> ; Pointer to the entry point of the PEI core
> ; It is located at 0xFFFFFFE0, and is fixed up by some build tool
> ; So if the value 8..1 appears in the final FD image, tool failure occurs.
> ;
> PeiCoreEntryPoint: DD 87654321h
>
>
> The reason you need special build rules is it is really hard to get code
> at the end of a PE/COFF file, so you need a stripped binary for the reset
> vector.
>
> The next problem is how do you get the FV File to be at the end of the FV
> (that is usually free space). The PI spec defines that if an FFS file has
> the File GUID of gEfiFirmwareVolumeTopFileGuid then it gets place at the
> end of the FV. Thus the X86 SEC must have this file guid. This also
> triggers the magic behavior to stitch the .com and PE/COFF together.
>
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.inf#L25
> FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
>
>
>
> For ARM things are much simpler. The FV reserves 16-bytes at the start of
> the volume for the reset vector. If the build tools see an FV has an ARM
> SEC it can patch in a branch to the SEC PE/COFF (TE) entry point (going
> from memory hopefully I did not botch that).
>
>
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L110
> ///
> /// The first 16 bytes are reserved to allow for the reset vector of
> /// processors whose reset vector is at address 0.
> ///
> UINT8 ZeroVector[16];
>
>
>
> PS.: Seems like inline images are not supported by the mailing list (or is
> it my error?). Either way, I do not see the image in my mail client
> (Outlook 2016).
>
>
> I don't see the image in my macOS Mail client.
>
> Thanks,
>
> Andrew Fish
>
>
> Regards,
> Marvin.
>
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
> <edk2-devel-bounces@lists.01.org>] On Behalf Of
> Rafael Machado
> Sent: Saturday, October 22, 2016 6:28 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Sec and Reset vector
>
> Hi eveyrone
>
> I'm doing some studies on edk2 and coreboot, but I'm having some questions
> that I believe you can help.
>
> On the journey to try to understand things since the beginning, so they
> make
> sense in future, I'm trying to understand how does the Initial phases of
> UEFI
> / PI firmware work. To do that I got a bios image and start to reverse it
> to
> check the modules and everything present at that bios. Now I understand, at
> least the basics, about DXE and PEI phase.
>
> The main question that I have now is about the SEC phase.
> To try to understand the SEC phase I tried to reverse this firmware so I
> could
> check the reset vector's first jump or something like that.
> The surprise I have is that I was not able to find this code.
>
> To be sure I was reversing on the correct way I generated a coreboot image.
> On the image below we can see the initial code of a firmware generated
> using coreboot
>
> [image: pasted1]
>
> But at the UEFI firmware I'm studying I'm not able to find anything
> similar to
> that.
> My guess before starting this was that at least the SEC initial code
> should be
> similar to the legacy way of doing things, a jmp at 0xfff:fff0 and after
> that the
> magic should get started with all uefi phases.
>
> Could someone please give me some light on that?
>
>
> Thanks and Regards
> Rafael R. Machado
> _______________________________________________
> 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: Sec and Reset vector

[Rafael Machado]

One additional information.
I checked the code mentioned by Andrew, and at the code things make sense.

Now I'd like to see that kind of initial code at the final binary.

Thanks
Rafael

Em sex, 4 de nov de 2016 às 15:48, Rafael Machado <
rafaelrodrigues.machado@gmail.com> escreveu:

> Hi everyone
>
> Thanks Andrew and Marvin for the clarification.
> Now things start to make sense.
>
> But I was still not able to understand were things start on a real binary
> On the attached image ResetVectorCoreboot.png we have the entry point on a
> coreboot image.
> What I would like to do is to find something similar to this on a UEFI
> Bios image.
>
> Based on Marvin's idea, I got the UEFI Tool and star to check the image I
> have.
> On the attached image TopFileInfo.png we can see to Top File mentioned by
> Andrew.
> The details about the Top File are these:
>
>   Offset: FF8018h
>
>   File GUID: 1BA0062E-C779-4582-8566-336AE8F78F09
>
>   Type: 03h
>
>   Attributes: 08h
>
>   Full size: 7FE8h (32744)
>
>   Header size: 18h (24)
>
>   Body size: 7FD0h (32720)
>
>   Tail size: 0h (0)
>
>   State: F8h
>
>   Header checksum: 99h, valid
>
>   Data checksum: AAh, valid
>
>   Header memory address: FFFF8018h
>
>   Data memory address: FFFF8030h
>
>   Compressed: No
>
>   Fixed: No
>
>
> I tried to find something similar to what I see at the coreboot image, but
> didn't find anything. Neither on the PE Image section, not on the Raw image
> sections.
>
>
> Any idea about how could I find the entry point of sec in this case?
>
> Thanks and Regards
> Rafael R. Machado
>
>
> Em sáb, 22 de out de 2016 às 16:19, Andrew Fish <afish@apple.com>
> escreveu:
>
> On Oct 22, 2016, at 10:03 AM, Marvin H?user <Marvin.Haeuser@outlook.com>
> wrote:
>
> Hey Rafael,
>
> There actually is some generic SEC code in UefiCpuPkg you might want to
> take a look at. It's generic because it does not have "Intel NDA" code,
> such as CAR (Cache-As-RAM) etc.
> The Reset Vector may or may not be part of SecCore. It's either embedded
> within the SecCore module, or a separate file in the FFS. You can check the
> start/end address of the modules (e.g. with UEFITool) and find the Reset
> Vector file that way.
>
>
> Rafael,
>
> There is some strange construction things going on with the SEC for X86.
>
> If you look in the FDF file you will see that the SEC is a PE/COFF (or TE)
> image and a raw binary for the 16-bit real mode reset vector code.
>
>
> https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L876
> [Rule.Common.SEC]
> FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
> PE32 PE32 Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
> RAW BIN Align = 16 |.com
> }
>
> The .com files are constructed from *.nasmb, *.asm16, or *.S16 files.
> https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32
>
> Special extensions are needed to have special build rules. The build rules
> are here:
>
> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template#L480
> Look at the [Masm16-Code-File] and [Nasm-to-Binary-Code-File] rules.
>
> The build tools also do some magic to stitch the .com and PE/COFF (TE)
> file together.
>
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb#L46
> ;
> ; Pointer to the entry point of the PEI core
> ; It is located at 0xFFFFFFE0, and is fixed up by some build tool
> ; So if the value 8..1 appears in the final FD image, tool failure occurs.
> ;
> PeiCoreEntryPoint: DD 87654321h
>
>
> The reason you need special build rules is it is really hard to get code
> at the end of a PE/COFF file, so you need a stripped binary for the reset
> vector.
>
> The next problem is how do you get the FV File to be at the end of the FV
> (that is usually free space). The PI spec defines that if an FFS file has
> the File GUID of gEfiFirmwareVolumeTopFileGuid then it gets place at the
> end of the FV. Thus the X86 SEC must have this file guid. This also
> triggers the magic behavior to stitch the .com and PE/COFF together.
>
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.inf#L25
> FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
>
>
>
> For ARM things are much simpler. The FV reserves 16-bytes at the start of
> the volume for the reset vector. If the build tools see an FV has an ARM
> SEC it can patch in a branch to the SEC PE/COFF (TE) entry point (going
> from memory hopefully I did not botch that).
>
>
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L110
> ///
> /// The first 16 bytes are reserved to allow for the reset vector of
> /// processors whose reset vector is at address 0.
> ///
> UINT8 ZeroVector[16];
>
>
>
> PS.: Seems like inline images are not supported by the mailing list (or is
> it my error?). Either way, I do not see the image in my mail client
> (Outlook 2016).
>
>
> I don't see the image in my macOS Mail client.
>
> Thanks,
>
> Andrew Fish
>
>
> Regards,
> Marvin.
>
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
> <edk2-devel-bounces@lists.01.org>] On Behalf Of
> Rafael Machado
> Sent: Saturday, October 22, 2016 6:28 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Sec and Reset vector
>
> Hi eveyrone
>
> I'm doing some studies on edk2 and coreboot, but I'm having some questions
> that I believe you can help.
>
> On the journey to try to understand things since the beginning, so they
> make
> sense in future, I'm trying to understand how does the Initial phases of
> UEFI
> / PI firmware work. To do that I got a bios image and start to reverse it
> to
> check the modules and everything present at that bios. Now I understand, at
> least the basics, about DXE and PEI phase.
>
> The main question that I have now is about the SEC phase.
> To try to understand the SEC phase I tried to reverse this firmware so I
> could
> check the reset vector's first jump or something like that.
> The surprise I have is that I was not able to find this code.
>
> To be sure I was reversing on the correct way I generated a coreboot image.
> On the image below we can see the initial code of a firmware generated
> using coreboot
>
> [image: pasted1]
>
> But at the UEFI firmware I'm studying I'm not able to find anything
> similar to
> that.
> My guess before starting this was that at least the SEC initial code
> should be
> similar to the legacy way of doing things, a jmp at 0xfff:fff0 and after
> that the
> magic should get started with all uefi phases.
>
> Could someone please give me some light on that?
>
>
> Thanks and Regards
> Rafael R. Machado
> _______________________________________________
> 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: Sec and Reset vector

[Andrew Fish]

> On Nov 4, 2016, at 10:48 AM, Rafael Machado <rafaelrodrigues.machado@gmail.com> wrote:
> 
> Hi everyone
> 
> Thanks Andrew and Marvin for the clarification.
> Now things start to make sense.
> 
> But I was still not able to understand were things start on a real binary

Rafeal,

I'm not sure what you are asking? 

The .com file contains the hardware real mode reset vector (0xFFFFFFF0). So execution starts up high. The 1st far jmp you do gets you running in the 0x000F**** range (the ROM is aliased to the old PC address). The .com file is patched with the entry point of the PE/COFF (or TE) .efi and just jumps into that code. At some point early in the processes the code transitions to protected mode and starts executing up high again (only a small part of the ROM is aliased down low).

The SEC PE/COFF  (or TE) .efi image entry point can be found in the PE/COFF (or TE) header that is part of that image. This is how the PEI Core passes control to PEIMs, and it is also what the PEI/DXE/SMM cores use to pass control to images that are loaded into memory. 

There is a library that given a PE/COFF or TE image will return the entry point. 

https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c#L44 <https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c#L44>
RETURN_STATUS
EFIAPI
PeCoffLoaderGetEntryPoint (
  IN  VOID  *Pe32Data,
  OUT VOID  **EntryPoint
  )
{
  EFI_IMAGE_DOS_HEADER                  *DosHdr;
  EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION   Hdr;

  ASSERT (Pe32Data   != NULL);
  ASSERT (EntryPoint != NULL);

  DosHdr = (EFI_IMAGE_DOS_HEADER *)Pe32Data;
  if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
    //
    // DOS image header is present, so read the PE header after the DOS image header.
    //
    Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)((UINTN) Pe32Data + (UINTN) ((DosHdr->e_lfanew) & 0x0ffff));
  } else {
    //
    // DOS image header is not present, so PE header is at the image base.
    //
    Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)Pe32Data;
  }

  //
  // Calculate the entry point relative to the start of the image.
  // AddressOfEntryPoint is common for PE32 & PE32+
  //
  if (Hdr.Te->Signature == EFI_TE_IMAGE_HEADER_SIGNATURE) {
    *EntryPoint = (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Te->AddressOfEntryPoint & 0x0ffffffff) + sizeof(EFI_TE_IMAGE_HEADER) - Hdr.Te->StrippedSize);
    return RETURN_SUCCESS;
  } else if (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE) {
    *EntryPoint = (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Pe32->OptionalHeader.AddressOfEntryPoint & 0x0ffffffff));
    return RETURN_SUCCESS;
  }

  return RETURN_UNSUPPORTED;
}



Thanks,

Andrew Fish   

> On the attached image ResetVectorCoreboot.png we have the entry point on a
> coreboot image.
> What I would like to do is to find something similar to this on a UEFI Bios
> image.
> 
> Based on Marvin's idea, I got the UEFI Tool and star to check the image I
> have.
> On the attached image TopFileInfo.png we can see to Top File mentioned by
> Andrew.
> The details about the Top File are these:
> 
>  Offset: FF8018h
> 
>  File GUID: 1BA0062E-C779-4582-8566-336AE8F78F09
> 
>  Type: 03h
> 
>  Attributes: 08h
> 
>  Full size: 7FE8h (32744)
> 
>  Header size: 18h (24)
> 
>  Body size: 7FD0h (32720)
> 
>  Tail size: 0h (0)
> 
>  State: F8h
> 
>  Header checksum: 99h, valid
> 
>  Data checksum: AAh, valid
> 
>  Header memory address: FFFF8018h
> 
>  Data memory address: FFFF8030h
> 
>  Compressed: No
> 
>  Fixed: No
> 
> 
> I tried to find something similar to what I see at the coreboot image, but
> didn't find anything. Neither on the PE Image section, not on the Raw image
> sections.
> 
> 
> Any idea about how could I find the entry point of sec in this case?
> 
> Thanks and Regards
> Rafael R. Machado
> 
> 
> Em sáb, 22 de out de 2016 às 16:19, Andrew Fish <afish@apple.com> escreveu:
> 
>> On Oct 22, 2016, at 10:03 AM, Marvin H?user <Marvin.Haeuser@outlook.com>
>> wrote:
>> 
>> Hey Rafael,
>> 
>> There actually is some generic SEC code in UefiCpuPkg you might want to
>> take a look at. It's generic because it does not have "Intel NDA" code,
>> such as CAR (Cache-As-RAM) etc.
>> The Reset Vector may or may not be part of SecCore. It's either embedded
>> within the SecCore module, or a separate file in the FFS. You can check the
>> start/end address of the modules (e.g. with UEFITool) and find the Reset
>> Vector file that way.
>> 
>> 
>> Rafael,
>> 
>> There is some strange construction things going on with the SEC for X86.
>> 
>> If you look in the FDF file you will see that the SEC is a PE/COFF (or TE)
>> image and a raw binary for the 16-bit real mode reset vector code.
>> 
>> 
>> https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L876
>> [Rule.Common.SEC]
>> FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
>> PE32 PE32 Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
>> RAW BIN Align = 16 |.com
>> }
>> 
>> The .com files are constructed from *.nasmb, *.asm16, or *.S16 files.
>> https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32
>> 
>> Special extensions are needed to have special build rules. The build rules
>> are here:
>> 
>> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template#L480
>> Look at the [Masm16-Code-File] and [Nasm-to-Binary-Code-File] rules.
>> 
>> The build tools also do some magic to stitch the .com and PE/COFF (TE)
>> file together.
>> 
>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb#L46
>> ;
>> ; Pointer to the entry point of the PEI core
>> ; It is located at 0xFFFFFFE0, and is fixed up by some build tool
>> ; So if the value 8..1 appears in the final FD image, tool failure occurs.
>> ;
>> PeiCoreEntryPoint: DD 87654321h
>> 
>> 
>> The reason you need special build rules is it is really hard to get code
>> at the end of a PE/COFF file, so you need a stripped binary for the reset
>> vector.
>> 
>> The next problem is how do you get the FV File to be at the end of the FV
>> (that is usually free space). The PI spec defines that if an FFS file has
>> the File GUID of gEfiFirmwareVolumeTopFileGuid then it gets place at the
>> end of the FV. Thus the X86 SEC must have this file guid. This also
>> triggers the magic behavior to stitch the .com and PE/COFF together.
>> 
>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.inf#L25
>> FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
>> 
>> 
>> 
>> For ARM things are much simpler. The FV reserves 16-bytes at the start of
>> the volume for the reset vector. If the build tools see an FV has an ARM
>> SEC it can patch in a branch to the SEC PE/COFF (TE) entry point (going
>> from memory hopefully I did not botch that).
>> 
>> 
>> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L110
>> ///
>> /// The first 16 bytes are reserved to allow for the reset vector of
>> /// processors whose reset vector is at address 0.
>> ///
>> UINT8 ZeroVector[16];
>> 
>> 
>> 
>> PS.: Seems like inline images are not supported by the mailing list (or is
>> it my error?). Either way, I do not see the image in my mail client
>> (Outlook 2016).
>> 
>> 
>> I don't see the image in my macOS Mail client.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> Regards,
>> Marvin.
>> 
>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
>> <edk2-devel-bounces@lists.01.org>] On Behalf Of
>> Rafael Machado
>> Sent: Saturday, October 22, 2016 6:28 PM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] Sec and Reset vector
>> 
>> Hi eveyrone
>> 
>> I'm doing some studies on edk2 and coreboot, but I'm having some questions
>> that I believe you can help.
>> 
>> On the journey to try to understand things since the beginning, so they
>> make
>> sense in future, I'm trying to understand how does the Initial phases of
>> UEFI
>> / PI firmware work. To do that I got a bios image and start to reverse it
>> to
>> check the modules and everything present at that bios. Now I understand, at
>> least the basics, about DXE and PEI phase.
>> 
>> The main question that I have now is about the SEC phase.
>> To try to understand the SEC phase I tried to reverse this firmware so I
>> could
>> check the reset vector's first jump or something like that.
>> The surprise I have is that I was not able to find this code.
>> 
>> To be sure I was reversing on the correct way I generated a coreboot image.
>> On the image below we can see the initial code of a firmware generated
>> using coreboot
>> 
>> [image: pasted1]
>> 
>> But at the UEFI firmware I'm studying I'm not able to find anything
>> similar to
>> that.
>> My guess before starting this was that at least the SEC initial code
>> should be
>> similar to the legacy way of doing things, a jmp at 0xfff:fff0 and after
>> that the
>> magic should get started with all uefi phases.
>> 
>> Could someone please give me some light on that?
>> 
>> 
>> Thanks and Regards
>> Rafael R. Machado
>> _______________________________________________
>> 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
>> 
>> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: Sec and Reset vector

[Rafael Machado]

Hi Andrew

Maybe my question was not clear.
But thanks for the information you provided.

I think we can simplify what I need based on your last comment. You told:

*"The .com file contains the hardware real mode reset vector (0xFFFFFFF0).
So execution starts up high. The 1st far jmp you do gets you running in the
0x000F**** range (the ROM is aliased to the old PC address)"*

How could I find the .com file inside the dump of a bios (I have used
DediProg to get the dump)?
I'm hunting the first far jump the firmware has.

Thanks
Rafael

Em sex, 4 de nov de 2016 às 16:50, Andrew Fish <afish@apple.com> escreveu:

> On Nov 4, 2016, at 10:48 AM, Rafael Machado <
> rafaelrodrigues.machado@gmail.com> wrote:
>
> Hi everyone
>
> Thanks Andrew and Marvin for the clarification.
> Now things start to make sense.
>
> But I was still not able to understand were things start on a real binary
>
>
> Rafeal,
>
> I'm not sure what you are asking?
>
> The .com file contains the hardware real mode reset vector (0xFFFFFFF0).
> So execution starts up high. The 1st far jmp you do gets you running in the
> 0x000F**** range (the ROM is aliased to the old PC address). The .com file
> is patched with the entry point of the PE/COFF (or TE) .efi and just jumps
> into that code. At some point early in the processes the code transitions
> to protected mode and starts executing up high again (only a small part of
> the ROM is aliased down low).
>
> The SEC PE/COFF  (or TE) .efi image entry point can be found in the
> PE/COFF (or TE) header that is part of that image. This is how the PEI Core
> passes control to PEIMs, and it is also what the PEI/DXE/SMM cores use to
> pass control to images that are loaded into memory.
>
> There is a library that given a PE/COFF or TE image will return the entry
> point.
>
>
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c#L44
> RETURN_STATUS
> EFIAPI
> PeCoffLoaderGetEntryPoint (
> IN VOID *Pe32Data,
> OUT VOID **EntryPoint
> )
> {
> EFI_IMAGE_DOS_HEADER *DosHdr;
> EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION Hdr;
> ASSERT (Pe32Data != NULL);
> ASSERT (EntryPoint != NULL);
> DosHdr = (EFI_IMAGE_DOS_HEADER *)Pe32Data;
> if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
> //
> // DOS image header is present, so read the PE header after the DOS image
> header.
> //
> Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)((UINTN) Pe32Data + (UINTN)
> ((DosHdr->e_lfanew) & 0x0ffff));
> } else {
> //
> // DOS image header is not present, so PE header is at the image base.
> //
> Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)Pe32Data;
> }
> //
> // Calculate the entry point relative to the start of the image.
> // AddressOfEntryPoint is common for PE32 & PE32+
> //
> if (Hdr.Te->Signature == EFI_TE_IMAGE_HEADER_SIGNATURE) {
> *EntryPoint = (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Te->AddressOfEntryPoint
> & 0x0ffffffff) + sizeof(EFI_TE_IMAGE_HEADER) - Hdr.Te->StrippedSize);
> return RETURN_SUCCESS;
> } else if (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE) {
> *EntryPoint = (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Pe32->OptionalHeader.
> AddressOfEntryPoint & 0x0ffffffff));
> return RETURN_SUCCESS;
> }
> return RETURN_UNSUPPORTED;
> }
>
>
> Thanks,
>
> Andrew Fish
>
> On the attached image ResetVectorCoreboot.png we have the entry point on a
> coreboot image.
> What I would like to do is to find something similar to this on a UEFI Bios
> image.
>
> Based on Marvin's idea, I got the UEFI Tool and star to check the image I
> have.
> On the attached image TopFileInfo.png we can see to Top File mentioned by
> Andrew.
> The details about the Top File are these:
>
>  Offset: FF8018h
>
>  File GUID: 1BA0062E-C779-4582-8566-336AE8F78F09
>
>  Type: 03h
>
>  Attributes: 08h
>
>  Full size: 7FE8h (32744)
>
>  Header size: 18h (24)
>
>  Body size: 7FD0h (32720)
>
>  Tail size: 0h (0)
>
>  State: F8h
>
>  Header checksum: 99h, valid
>
>  Data checksum: AAh, valid
>
>  Header memory address: FFFF8018h
>
>  Data memory address: FFFF8030h
>
>  Compressed: No
>
>  Fixed: No
>
>
> I tried to find something similar to what I see at the coreboot image, but
> didn't find anything. Neither on the PE Image section, not on the Raw image
> sections.
>
>
> Any idea about how could I find the entry point of sec in this case?
>
> Thanks and Regards
> Rafael R. Machado
>
>
> Em sáb, 22 de out de 2016 às 16:19, Andrew Fish <afish@apple.com>
> escreveu:
>
> On Oct 22, 2016, at 10:03 AM, Marvin H?user <Marvin.Haeuser@outlook.com>
> wrote:
>
> Hey Rafael,
>
> There actually is some generic SEC code in UefiCpuPkg you might want to
> take a look at. It's generic because it does not have "Intel NDA" code,
> such as CAR (Cache-As-RAM) etc.
> The Reset Vector may or may not be part of SecCore. It's either embedded
> within the SecCore module, or a separate file in the FFS. You can check the
> start/end address of the modules (e.g. with UEFITool) and find the Reset
> Vector file that way.
>
>
> Rafael,
>
> There is some strange construction things going on with the SEC for X86.
>
> If you look in the FDF file you will see that the SEC is a PE/COFF (or TE)
> image and a raw binary for the 16-bit real mode reset vector code.
>
>
>
> https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L876
> [Rule.Common.SEC]
> FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
> PE32 PE32 Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
> RAW BIN Align = 16 |.com
> }
>
> The .com files are constructed from *.nasmb, *.asm16, or *.S16 files.
> https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32
>
> Special extensions are needed to have special build rules. The build rules
> are here:
>
>
> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template#L480
> Look at the [Masm16-Code-File] and [Nasm-to-Binary-Code-File] rules.
>
> The build tools also do some magic to stitch the .com and PE/COFF (TE)
> file together.
>
>
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb#L46
> ;
> ; Pointer to the entry point of the PEI core
> ; It is located at 0xFFFFFFE0, and is fixed up by some build tool
> ; So if the value 8..1 appears in the final FD image, tool failure occurs.
> ;
> PeiCoreEntryPoint: DD 87654321h
>
>
> The reason you need special build rules is it is really hard to get code
> at the end of a PE/COFF file, so you need a stripped binary for the reset
> vector.
>
> The next problem is how do you get the FV File to be at the end of the FV
> (that is usually free space). The PI spec defines that if an FFS file has
> the File GUID of gEfiFirmwareVolumeTopFileGuid then it gets place at the
> end of the FV. Thus the X86 SEC must have this file guid. This also
> triggers the magic behavior to stitch the .com and PE/COFF together.
>
>
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.inf#L25
> FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
>
>
>
> For ARM things are much simpler. The FV reserves 16-bytes at the start of
> the volume for the reset vector. If the build tools see an FV has an ARM
> SEC it can patch in a branch to the SEC PE/COFF (TE) entry point (going
> from memory hopefully I did not botch that).
>
>
>
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L110
> ///
> /// The first 16 bytes are reserved to allow for the reset vector of
> /// processors whose reset vector is at address 0.
> ///
> UINT8 ZeroVector[16];
>
>
>
> PS.: Seems like inline images are not supported by the mailing list (or is
> it my error?). Either way, I do not see the image in my mail client
> (Outlook 2016).
>
>
> I don't see the image in my macOS Mail client.
>
> Thanks,
>
> Andrew Fish
>
>
> Regards,
> Marvin.
>
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
> <edk2-devel-bounces@lists.01.org>] On Behalf Of
> Rafael Machado
> Sent: Saturday, October 22, 2016 6:28 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Sec and Reset vector
>
> Hi eveyrone
>
> I'm doing some studies on edk2 and coreboot, but I'm having some questions
> that I believe you can help.
>
> On the journey to try to understand things since the beginning, so they
> make
> sense in future, I'm trying to understand how does the Initial phases of
> UEFI
> / PI firmware work. To do that I got a bios image and start to reverse it
> to
> check the modules and everything present at that bios. Now I understand, at
> least the basics, about DXE and PEI phase.
>
> The main question that I have now is about the SEC phase.
> To try to understand the SEC phase I tried to reverse this firmware so I
> could
> check the reset vector's first jump or something like that.
> The surprise I have is that I was not able to find this code.
>
> To be sure I was reversing on the correct way I generated a coreboot image.
> On the image below we can see the initial code of a firmware generated
> using coreboot
>
> [image: pasted1]
>
> But at the UEFI firmware I'm studying I'm not able to find anything
> similar to
> that.
> My guess before starting this was that at least the SEC initial code
> should be
> similar to the legacy way of doing things, a jmp at 0xfff:fff0 and after
> that the
> magic should get started with all uefi phases.
>
> Could someone please give me some light on that?
>
>
> Thanks and Regards
> Rafael R. Machado
> _______________________________________________
> 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
>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
>

Re: Sec and Reset vector

[Laszlo Ersek]

On 11/04/16 20:33, Rafael Machado wrote:
> Hi Andrew
> 
> Maybe my question was not clear.
> But thanks for the information you provided.
> 
> I think we can simplify what I need based on your last comment. You told:
> 
> *"The .com file contains the hardware real mode reset vector (0xFFFFFFF0).
> So execution starts up high. The 1st far jmp you do gets you running in the
> 0x000F**** range (the ROM is aliased to the old PC address)"*
> 
> How could I find the .com file inside the dump of a bios (I have used
> DediProg to get the dump)?
> I'm hunting the first far jump the firmware has.

(I have zero context, but that shan't prevent me from butting in:)

it's called VTF (volume top file), and (I think) it should be at the
very end of the stuff that you dumped from the flash chip. That's how
the relevant contents show up just below 4GB, I presume.

Laszlo

> 
> Thanks
> Rafael
> 
> Em sex, 4 de nov de 2016 às 16:50, Andrew Fish <afish@apple.com> escreveu:
> 
>> On Nov 4, 2016, at 10:48 AM, Rafael Machado <
>> rafaelrodrigues.machado@gmail.com> wrote:
>>
>> Hi everyone
>>
>> Thanks Andrew and Marvin for the clarification.
>> Now things start to make sense.
>>
>> But I was still not able to understand were things start on a real binary
>>
>>
>> Rafeal,
>>
>> I'm not sure what you are asking?
>>
>> The .com file contains the hardware real mode reset vector (0xFFFFFFF0).
>> So execution starts up high. The 1st far jmp you do gets you running in the
>> 0x000F**** range (the ROM is aliased to the old PC address). The .com file
>> is patched with the entry point of the PE/COFF (or TE) .efi and just jumps
>> into that code. At some point early in the processes the code transitions
>> to protected mode and starts executing up high again (only a small part of
>> the ROM is aliased down low).
>>
>> The SEC PE/COFF  (or TE) .efi image entry point can be found in the
>> PE/COFF (or TE) header that is part of that image. This is how the PEI Core
>> passes control to PEIMs, and it is also what the PEI/DXE/SMM cores use to
>> pass control to images that are loaded into memory.
>>
>> There is a library that given a PE/COFF or TE image will return the entry
>> point.
>>
>>
>> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c#L44
>> RETURN_STATUS
>> EFIAPI
>> PeCoffLoaderGetEntryPoint (
>> IN VOID *Pe32Data,
>> OUT VOID **EntryPoint
>> )
>> {
>> EFI_IMAGE_DOS_HEADER *DosHdr;
>> EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION Hdr;
>> ASSERT (Pe32Data != NULL);
>> ASSERT (EntryPoint != NULL);
>> DosHdr = (EFI_IMAGE_DOS_HEADER *)Pe32Data;
>> if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
>> //
>> // DOS image header is present, so read the PE header after the DOS image
>> header.
>> //
>> Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)((UINTN) Pe32Data + (UINTN)
>> ((DosHdr->e_lfanew) & 0x0ffff));
>> } else {
>> //
>> // DOS image header is not present, so PE header is at the image base.
>> //
>> Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)Pe32Data;
>> }
>> //
>> // Calculate the entry point relative to the start of the image.
>> // AddressOfEntryPoint is common for PE32 & PE32+
>> //
>> if (Hdr.Te->Signature == EFI_TE_IMAGE_HEADER_SIGNATURE) {
>> *EntryPoint = (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Te->AddressOfEntryPoint
>> & 0x0ffffffff) + sizeof(EFI_TE_IMAGE_HEADER) - Hdr.Te->StrippedSize);
>> return RETURN_SUCCESS;
>> } else if (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE) {
>> *EntryPoint = (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Pe32->OptionalHeader.
>> AddressOfEntryPoint & 0x0ffffffff));
>> return RETURN_SUCCESS;
>> }
>> return RETURN_UNSUPPORTED;
>> }
>>
>>
>> Thanks,
>>
>> Andrew Fish
>>
>> On the attached image ResetVectorCoreboot.png we have the entry point on a
>> coreboot image.
>> What I would like to do is to find something similar to this on a UEFI Bios
>> image.
>>
>> Based on Marvin's idea, I got the UEFI Tool and star to check the image I
>> have.
>> On the attached image TopFileInfo.png we can see to Top File mentioned by
>> Andrew.
>> The details about the Top File are these:
>>
>>  Offset: FF8018h
>>
>>  File GUID: 1BA0062E-C779-4582-8566-336AE8F78F09
>>
>>  Type: 03h
>>
>>  Attributes: 08h
>>
>>  Full size: 7FE8h (32744)
>>
>>  Header size: 18h (24)
>>
>>  Body size: 7FD0h (32720)
>>
>>  Tail size: 0h (0)
>>
>>  State: F8h
>>
>>  Header checksum: 99h, valid
>>
>>  Data checksum: AAh, valid
>>
>>  Header memory address: FFFF8018h
>>
>>  Data memory address: FFFF8030h
>>
>>  Compressed: No
>>
>>  Fixed: No
>>
>>
>> I tried to find something similar to what I see at the coreboot image, but
>> didn't find anything. Neither on the PE Image section, not on the Raw image
>> sections.
>>
>>
>> Any idea about how could I find the entry point of sec in this case?
>>
>> Thanks and Regards
>> Rafael R. Machado
>>
>>
>> Em sáb, 22 de out de 2016 às 16:19, Andrew Fish <afish@apple.com>
>> escreveu:
>>
>> On Oct 22, 2016, at 10:03 AM, Marvin H?user <Marvin.Haeuser@outlook.com>
>> wrote:
>>
>> Hey Rafael,
>>
>> There actually is some generic SEC code in UefiCpuPkg you might want to
>> take a look at. It's generic because it does not have "Intel NDA" code,
>> such as CAR (Cache-As-RAM) etc.
>> The Reset Vector may or may not be part of SecCore. It's either embedded
>> within the SecCore module, or a separate file in the FFS. You can check the
>> start/end address of the modules (e.g. with UEFITool) and find the Reset
>> Vector file that way.
>>
>>
>> Rafael,
>>
>> There is some strange construction things going on with the SEC for X86.
>>
>> If you look in the FDF file you will see that the SEC is a PE/COFF (or TE)
>> image and a raw binary for the 16-bit real mode reset vector code.
>>
>>
>>
>> https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L876
>> [Rule.Common.SEC]
>> FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
>> PE32 PE32 Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
>> RAW BIN Align = 16 |.com
>> }
>>
>> The .com files are constructed from *.nasmb, *.asm16, or *.S16 files.
>> https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32
>>
>> Special extensions are needed to have special build rules. The build rules
>> are here:
>>
>>
>> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template#L480
>> Look at the [Masm16-Code-File] and [Nasm-to-Binary-Code-File] rules.
>>
>> The build tools also do some magic to stitch the .com and PE/COFF (TE)
>> file together.
>>
>>
>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb#L46
>> ;
>> ; Pointer to the entry point of the PEI core
>> ; It is located at 0xFFFFFFE0, and is fixed up by some build tool
>> ; So if the value 8..1 appears in the final FD image, tool failure occurs.
>> ;
>> PeiCoreEntryPoint: DD 87654321h
>>
>>
>> The reason you need special build rules is it is really hard to get code
>> at the end of a PE/COFF file, so you need a stripped binary for the reset
>> vector.
>>
>> The next problem is how do you get the FV File to be at the end of the FV
>> (that is usually free space). The PI spec defines that if an FFS file has
>> the File GUID of gEfiFirmwareVolumeTopFileGuid then it gets place at the
>> end of the FV. Thus the X86 SEC must have this file guid. This also
>> triggers the magic behavior to stitch the .com and PE/COFF together.
>>
>>
>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.inf#L25
>> FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
>>
>>
>>
>> For ARM things are much simpler. The FV reserves 16-bytes at the start of
>> the volume for the reset vector. If the build tools see an FV has an ARM
>> SEC it can patch in a branch to the SEC PE/COFF (TE) entry point (going
>> from memory hopefully I did not botch that).
>>
>>
>>
>> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L110
>> ///
>> /// The first 16 bytes are reserved to allow for the reset vector of
>> /// processors whose reset vector is at address 0.
>> ///
>> UINT8 ZeroVector[16];
>>
>>
>>
>> PS.: Seems like inline images are not supported by the mailing list (or is
>> it my error?). Either way, I do not see the image in my mail client
>> (Outlook 2016).
>>
>>
>> I don't see the image in my macOS Mail client.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>
>> Regards,
>> Marvin.
>>
>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
>> <edk2-devel-bounces@lists.01.org>] On Behalf Of
>> Rafael Machado
>> Sent: Saturday, October 22, 2016 6:28 PM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] Sec and Reset vector
>>
>> Hi eveyrone
>>
>> I'm doing some studies on edk2 and coreboot, but I'm having some questions
>> that I believe you can help.
>>
>> On the journey to try to understand things since the beginning, so they
>> make
>> sense in future, I'm trying to understand how does the Initial phases of
>> UEFI
>> / PI firmware work. To do that I got a bios image and start to reverse it
>> to
>> check the modules and everything present at that bios. Now I understand, at
>> least the basics, about DXE and PEI phase.
>>
>> The main question that I have now is about the SEC phase.
>> To try to understand the SEC phase I tried to reverse this firmware so I
>> could
>> check the reset vector's first jump or something like that.
>> The surprise I have is that I was not able to find this code.
>>
>> To be sure I was reversing on the correct way I generated a coreboot image.
>> On the image below we can see the initial code of a firmware generated
>> using coreboot
>>
>> [image: pasted1]
>>
>> But at the UEFI firmware I'm studying I'm not able to find anything
>> similar to
>> that.
>> My guess before starting this was that at least the SEC initial code
>> should be
>> similar to the legacy way of doing things, a jmp at 0xfff:fff0 and after
>> that the
>> magic should get started with all uefi phases.
>>
>> Could someone please give me some light on that?
>>
>>
>> Thanks and Regards
>> Rafael R. Machado
>> _______________________________________________
>> 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
>>
>>
>> _______________________________________________
>> 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: Sec and Reset vector

[Andrew Fish]

> On Nov 4, 2016, at 12:59 PM, Laszlo Ersek <lersek@redhat.com> wrote:
> 
> On 11/04/16 20:33, Rafael Machado wrote:
>> Hi Andrew
>> 
>> Maybe my question was not clear.
>> But thanks for the information you provided.
>> 
>> I think we can simplify what I need based on your last comment. You told:
>> 
>> *"The .com file contains the hardware real mode reset vector (0xFFFFFFF0).
>> So execution starts up high. The 1st far jmp you do gets you running in the
>> 0x000F**** range (the ROM is aliased to the old PC address)"*
>> 
>> How could I find the .com file inside the dump of a bios (I have used
>> DediProg to get the dump)?

Rafael,

Just dump the FV. The edk2 has the VolInfo command and you can pass --offset OFFSET.  There are other fancier GUI tools around, but I've never used them.  There is a signature in the FV Header that you should be able to find and use to figure out the start of the FVs in your extracted FD.

The FV with the SEC will look something like:

FV Header
FV Block Map

FFS File 1
FFS File 2
.....
FFS File N-1
Pad File
FFS File N


The FFS File N will have the VolumeTop GUID for the FFS filename. 

An FFS file looks like:
FFS Header
Section 1 Header
Section 1 Data
Section 2 Header
Section 2 Data

In our case Section 1 is the SEC .efi and Section 2 is the .com file. 

The FV layout is defined in the PI Specs and all the definitions are in the MdePkg. 


>> I'm hunting the first far jump the firmware has.
> 

Well the 1st instruction is real mode and 16 bytes from the end of the ROM. You can start disassembling there and follow the code? While the code is still in real mode you can assume the last 64K of the ROM image is mapped to 0x000F0000, when you transition to protected mode then that last 64K is going to map to 0xFFFF0000, also it could be bigger than 64K. 

> (I have zero context, but that shan't prevent me from butting in:)
> 

Likewise! I'm sure some of those playing at home have a better understanding of how the SEC is constructed after this thread so a good answer to the wrong question does not always go unused. 

Thanks,

Andrew Fish

> it's called VTF (volume top file), and (I think) it should be at the
> very end of the stuff that you dumped from the flash chip. That's how
> the relevant contents show up just below 4GB, I presume.
> 





> Laszlo
> 
>> 
>> Thanks
>> Rafael
>> 
>> Em sex, 4 de nov de 2016 às 16:50, Andrew Fish <afish@apple.com> escreveu:
>> 
>>> On Nov 4, 2016, at 10:48 AM, Rafael Machado <
>>> rafaelrodrigues.machado@gmail.com> wrote:
>>> 
>>> Hi everyone
>>> 
>>> Thanks Andrew and Marvin for the clarification.
>>> Now things start to make sense.
>>> 
>>> But I was still not able to understand were things start on a real binary
>>> 
>>> 
>>> Rafeal,
>>> 
>>> I'm not sure what you are asking?
>>> 
>>> The .com file contains the hardware real mode reset vector (0xFFFFFFF0).
>>> So execution starts up high. The 1st far jmp you do gets you running in the
>>> 0x000F**** range (the ROM is aliased to the old PC address). The .com file
>>> is patched with the entry point of the PE/COFF (or TE) .efi and just jumps
>>> into that code. At some point early in the processes the code transitions
>>> to protected mode and starts executing up high again (only a small part of
>>> the ROM is aliased down low).
>>> 
>>> The SEC PE/COFF  (or TE) .efi image entry point can be found in the
>>> PE/COFF (or TE) header that is part of that image. This is how the PEI Core
>>> passes control to PEIMs, and it is also what the PEI/DXE/SMM cores use to
>>> pass control to images that are loaded into memory.
>>> 
>>> There is a library that given a PE/COFF or TE image will return the entry
>>> point.
>>> 
>>> 
>>> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BasePeCoffGetEntryPointLib/PeCoffGetEntryPoint.c#L44
>>> RETURN_STATUS
>>> EFIAPI
>>> PeCoffLoaderGetEntryPoint (
>>> IN VOID *Pe32Data,
>>> OUT VOID **EntryPoint
>>> )
>>> {
>>> EFI_IMAGE_DOS_HEADER *DosHdr;
>>> EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION Hdr;
>>> ASSERT (Pe32Data != NULL);
>>> ASSERT (EntryPoint != NULL);
>>> DosHdr = (EFI_IMAGE_DOS_HEADER *)Pe32Data;
>>> if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
>>> //
>>> // DOS image header is present, so read the PE header after the DOS image
>>> header.
>>> //
>>> Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)((UINTN) Pe32Data + (UINTN)
>>> ((DosHdr->e_lfanew) & 0x0ffff));
>>> } else {
>>> //
>>> // DOS image header is not present, so PE header is at the image base.
>>> //
>>> Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)Pe32Data;
>>> }
>>> //
>>> // Calculate the entry point relative to the start of the image.
>>> // AddressOfEntryPoint is common for PE32 & PE32+
>>> //
>>> if (Hdr.Te->Signature == EFI_TE_IMAGE_HEADER_SIGNATURE) {
>>> *EntryPoint = (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Te->AddressOfEntryPoint
>>> & 0x0ffffffff) + sizeof(EFI_TE_IMAGE_HEADER) - Hdr.Te->StrippedSize);
>>> return RETURN_SUCCESS;
>>> } else if (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE) {
>>> *EntryPoint = (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Pe32->OptionalHeader.
>>> AddressOfEntryPoint & 0x0ffffffff));
>>> return RETURN_SUCCESS;
>>> }
>>> return RETURN_UNSUPPORTED;
>>> }
>>> 
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>> On the attached image ResetVectorCoreboot.png we have the entry point on a
>>> coreboot image.
>>> What I would like to do is to find something similar to this on a UEFI Bios
>>> image.
>>> 
>>> Based on Marvin's idea, I got the UEFI Tool and star to check the image I
>>> have.
>>> On the attached image TopFileInfo.png we can see to Top File mentioned by
>>> Andrew.
>>> The details about the Top File are these:
>>> 
>>> Offset: FF8018h
>>> 
>>> File GUID: 1BA0062E-C779-4582-8566-336AE8F78F09
>>> 
>>> Type: 03h
>>> 
>>> Attributes: 08h
>>> 
>>> Full size: 7FE8h (32744)
>>> 
>>> Header size: 18h (24)
>>> 
>>> Body size: 7FD0h (32720)
>>> 
>>> Tail size: 0h (0)
>>> 
>>> State: F8h
>>> 
>>> Header checksum: 99h, valid
>>> 
>>> Data checksum: AAh, valid
>>> 
>>> Header memory address: FFFF8018h
>>> 
>>> Data memory address: FFFF8030h
>>> 
>>> Compressed: No
>>> 
>>> Fixed: No
>>> 
>>> 
>>> I tried to find something similar to what I see at the coreboot image, but
>>> didn't find anything. Neither on the PE Image section, not on the Raw image
>>> sections.
>>> 
>>> 
>>> Any idea about how could I find the entry point of sec in this case?
>>> 
>>> Thanks and Regards
>>> Rafael R. Machado
>>> 
>>> 
>>> Em sáb, 22 de out de 2016 às 16:19, Andrew Fish <afish@apple.com>
>>> escreveu:
>>> 
>>> On Oct 22, 2016, at 10:03 AM, Marvin H?user <Marvin.Haeuser@outlook.com>
>>> wrote:
>>> 
>>> Hey Rafael,
>>> 
>>> There actually is some generic SEC code in UefiCpuPkg you might want to
>>> take a look at. It's generic because it does not have "Intel NDA" code,
>>> such as CAR (Cache-As-RAM) etc.
>>> The Reset Vector may or may not be part of SecCore. It's either embedded
>>> within the SecCore module, or a separate file in the FFS. You can check the
>>> start/end address of the modules (e.g. with UEFITool) and find the Reset
>>> Vector file that way.
>>> 
>>> 
>>> Rafael,
>>> 
>>> There is some strange construction things going on with the SEC for X86.
>>> 
>>> If you look in the FDF file you will see that the SEC is a PE/COFF (or TE)
>>> image and a raw binary for the 16-bit real mode reset vector code.
>>> 
>>> 
>>> 
>>> https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L876
>>> [Rule.Common.SEC]
>>> FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
>>> PE32 PE32 Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
>>> RAW BIN Align = 16 |.com
>>> }
>>> 
>>> The .com files are constructed from *.nasmb, *.asm16, or *.S16 files.
>>> https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32
>>> 
>>> Special extensions are needed to have special build rules. The build rules
>>> are here:
>>> 
>>> 
>>> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template#L480
>>> Look at the [Masm16-Code-File] and [Nasm-to-Binary-Code-File] rules.
>>> 
>>> The build tools also do some magic to stitch the .com and PE/COFF (TE)
>>> file together.
>>> 
>>> 
>>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb#L46
>>> ;
>>> ; Pointer to the entry point of the PEI core
>>> ; It is located at 0xFFFFFFE0, and is fixed up by some build tool
>>> ; So if the value 8..1 appears in the final FD image, tool failure occurs.
>>> ;
>>> PeiCoreEntryPoint: DD 87654321h
>>> 
>>> 
>>> The reason you need special build rules is it is really hard to get code
>>> at the end of a PE/COFF file, so you need a stripped binary for the reset
>>> vector.
>>> 
>>> The next problem is how do you get the FV File to be at the end of the FV
>>> (that is usually free space). The PI spec defines that if an FFS file has
>>> the File GUID of gEfiFirmwareVolumeTopFileGuid then it gets place at the
>>> end of the FV. Thus the X86 SEC must have this file guid. This also
>>> triggers the magic behavior to stitch the .com and PE/COFF together.
>>> 
>>> 
>>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.inf#L25
>>> FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
>>> 
>>> 
>>> 
>>> For ARM things are much simpler. The FV reserves 16-bytes at the start of
>>> the volume for the reset vector. If the build tools see an FV has an ARM
>>> SEC it can patch in a branch to the SEC PE/COFF (TE) entry point (going
>>> from memory hopefully I did not botch that).
>>> 
>>> 
>>> 
>>> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L110
>>> ///
>>> /// The first 16 bytes are reserved to allow for the reset vector of
>>> /// processors whose reset vector is at address 0.
>>> ///
>>> UINT8 ZeroVector[16];
>>> 
>>> 
>>> 
>>> PS.: Seems like inline images are not supported by the mailing list (or is
>>> it my error?). Either way, I do not see the image in my mail client
>>> (Outlook 2016).
>>> 
>>> 
>>> I don't see the image in my macOS Mail client.
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>> 
>>> Regards,
>>> Marvin.
>>> 
>>> -----Original Message-----
>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
>>> <edk2-devel-bounces@lists.01.org>] On Behalf Of
>>> Rafael Machado
>>> Sent: Saturday, October 22, 2016 6:28 PM
>>> To: edk2-devel@lists.01.org
>>> Subject: [edk2] Sec and Reset vector
>>> 
>>> Hi eveyrone
>>> 
>>> I'm doing some studies on edk2 and coreboot, but I'm having some questions
>>> that I believe you can help.
>>> 
>>> On the journey to try to understand things since the beginning, so they
>>> make
>>> sense in future, I'm trying to understand how does the Initial phases of
>>> UEFI
>>> / PI firmware work. To do that I got a bios image and start to reverse it
>>> to
>>> check the modules and everything present at that bios. Now I understand, at
>>> least the basics, about DXE and PEI phase.
>>> 
>>> The main question that I have now is about the SEC phase.
>>> To try to understand the SEC phase I tried to reverse this firmware so I
>>> could
>>> check the reset vector's first jump or something like that.
>>> The surprise I have is that I was not able to find this code.
>>> 
>>> To be sure I was reversing on the correct way I generated a coreboot image.
>>> On the image below we can see the initial code of a firmware generated
>>> using coreboot
>>> 
>>> [image: pasted1]
>>> 
>>> But at the UEFI firmware I'm studying I'm not able to find anything
>>> similar to
>>> that.
>>> My guess before starting this was that at least the SEC initial code
>>> should be
>>> similar to the legacy way of doing things, a jmp at 0xfff:fff0 and after
>>> that the
>>> magic should get started with all uefi phases.
>>> 
>>> Could someone please give me some light on that?
>>> 
>>> 
>>> Thanks and Regards
>>> Rafael R. Machado
>>> _______________________________________________
>>> 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
>>> 
>>> 
>>> _______________________________________________
>>> 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 <mailto:edk2-devel@lists.01.org>
>> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>

Re: Sec and Reset vector

[Kinney, Michael D]

Rafael,

The first instruction executed for IA32 SEC phase is typically 16-bytes from
the end of the Firmware Device (FD) image generated by a build.

If you look at QuarkPlatformPkg/Quark.dsc as an example build, it generates 
an 8MB  file called Quark.FD.  The reset vector is 16-bytes from the end of
that file.  The reset vector and rest of SEC code are all in a special FFS file
known at the Volume Top File(VFT).  

The source code for the reset vector is in the file:

	UefiCpuPkg/SecCore/Ia32/ResetVector.nasmb

This source file contains the code that fills the last 0x40 bytes of the VTF
which is also the last 0x40 bytes of Quark.FD.

The build tools do some special fixups on this file, so 16-bit relative JMP
instruction at line 79 is fixed up to jump to the symbol _ModuleEntryPoint.

	ResetHandler:
	    nop
	    nop
	ApStartup:
	    ;
	    ; Jmp Rel16 instruction
	    ; Use machine code directly in case of the assembler optimization
	    ; SEC entry point relative address will be fixed up by some build tool.
	    ;
	    ; Typically, SEC entry point is the function _ModuleEntryPoint() defined in
	    ; SecEntry.asm
	    ;
	    DB      0e9h
	    DW      -3

For Quark.FD, _ModuleEntryPoint is from the PlatformSecLib library at:

	QuarkPlatformPkg/Library/PlatformSecLib

Specifically Line l5 of the file:

	QuarkPlatformPkg/Library/PlatformSecLib/Ia32/Flat32.asm

_ModuleEntryEntryPoint starts in 16-bit real mode and transitions to 
32-bit protected mode, initializes ESRAM to be used as a stack, and
transfers control to the C function PlatformSecLibStartup() at line 220.
The goal is to minimize the amount of assembly code and get into C code
as quickly as possible.

The PlatformSecLibStartup() function implementation is in the same 
PlatformSecLib library at line 68 of the file:

	QuarkPlatformPkg/Library/PlatformSecLib/PlatformSecLib.c

Best regards,

Mike

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Rafael Machado
> Sent: Friday, November 4, 2016 12:34 PM
> To: Andrew Fish <afish@apple.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Sec and Reset vector
> 
> Hi Andrew
> 
> Maybe my question was not clear.
> But thanks for the information you provided.
> 
> I think we can simplify what I need based on your last comment. You told:
> 
> *"The .com file contains the hardware real mode reset vector (0xFFFFFFF0).
> So execution starts up high. The 1st far jmp you do gets you running in the
> 0x000F**** range (the ROM is aliased to the old PC address)"*
> 
> How could I find the .com file inside the dump of a bios (I have used
> DediProg to get the dump)?
> I'm hunting the first far jump the firmware has.
> 
> Thanks
> Rafael
> 
> Em sex, 4 de nov de 2016 às 16:50, Andrew Fish <afish@apple.com> escreveu:
> 
> > On Nov 4, 2016, at 10:48 AM, Rafael Machado <
> > rafaelrodrigues.machado@gmail.com> wrote:
> >
> > Hi everyone
> >
> > Thanks Andrew and Marvin for the clarification.
> > Now things start to make sense.
> >
> > But I was still not able to understand were things start on a real binary
> >
> >
> > Rafeal,
> >
> > I'm not sure what you are asking?
> >
> > The .com file contains the hardware real mode reset vector (0xFFFFFFF0).
> > So execution starts up high. The 1st far jmp you do gets you running in the
> > 0x000F**** range (the ROM is aliased to the old PC address). The .com file
> > is patched with the entry point of the PE/COFF (or TE) .efi and just jumps
> > into that code. At some point early in the processes the code transitions
> > to protected mode and starts executing up high again (only a small part of
> > the ROM is aliased down low).
> >
> > The SEC PE/COFF  (or TE) .efi image entry point can be found in the
> > PE/COFF (or TE) header that is part of that image. This is how the PEI Core
> > passes control to PEIMs, and it is also what the PEI/DXE/SMM cores use to
> > pass control to images that are loaded into memory.
> >
> > There is a library that given a PE/COFF or TE image will return the entry
> > point.
> >
> >
> >
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BasePeCoffGetEntryPointL
> ib/PeCoffGetEntryPoint.c#L44
> > RETURN_STATUS
> > EFIAPI
> > PeCoffLoaderGetEntryPoint (
> > IN VOID *Pe32Data,
> > OUT VOID **EntryPoint
> > )
> > {
> > EFI_IMAGE_DOS_HEADER *DosHdr;
> > EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION Hdr;
> > ASSERT (Pe32Data != NULL);
> > ASSERT (EntryPoint != NULL);
> > DosHdr = (EFI_IMAGE_DOS_HEADER *)Pe32Data;
> > if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
> > //
> > // DOS image header is present, so read the PE header after the DOS image
> > header.
> > //
> > Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)((UINTN) Pe32Data + (UINTN)
> > ((DosHdr->e_lfanew) & 0x0ffff));
> > } else {
> > //
> > // DOS image header is not present, so PE header is at the image base.
> > //
> > Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)Pe32Data;
> > }
> > //
> > // Calculate the entry point relative to the start of the image.
> > // AddressOfEntryPoint is common for PE32 & PE32+
> > //
> > if (Hdr.Te->Signature == EFI_TE_IMAGE_HEADER_SIGNATURE) {
> > *EntryPoint = (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Te->AddressOfEntryPoint
> > & 0x0ffffffff) + sizeof(EFI_TE_IMAGE_HEADER) - Hdr.Te->StrippedSize);
> > return RETURN_SUCCESS;
> > } else if (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE) {
> > *EntryPoint = (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Pe32->OptionalHeader.
> > AddressOfEntryPoint & 0x0ffffffff));
> > return RETURN_SUCCESS;
> > }
> > return RETURN_UNSUPPORTED;
> > }
> >
> >
> > Thanks,
> >
> > Andrew Fish
> >
> > On the attached image ResetVectorCoreboot.png we have the entry point on a
> > coreboot image.
> > What I would like to do is to find something similar to this on a UEFI Bios
> > image.
> >
> > Based on Marvin's idea, I got the UEFI Tool and star to check the image I
> > have.
> > On the attached image TopFileInfo.png we can see to Top File mentioned by
> > Andrew.
> > The details about the Top File are these:
> >
> >  Offset: FF8018h
> >
> >  File GUID: 1BA0062E-C779-4582-8566-336AE8F78F09
> >
> >  Type: 03h
> >
> >  Attributes: 08h
> >
> >  Full size: 7FE8h (32744)
> >
> >  Header size: 18h (24)
> >
> >  Body size: 7FD0h (32720)
> >
> >  Tail size: 0h (0)
> >
> >  State: F8h
> >
> >  Header checksum: 99h, valid
> >
> >  Data checksum: AAh, valid
> >
> >  Header memory address: FFFF8018h
> >
> >  Data memory address: FFFF8030h
> >
> >  Compressed: No
> >
> >  Fixed: No
> >
> >
> > I tried to find something similar to what I see at the coreboot image, but
> > didn't find anything. Neither on the PE Image section, not on the Raw image
> > sections.
> >
> >
> > Any idea about how could I find the entry point of sec in this case?
> >
> > Thanks and Regards
> > Rafael R. Machado
> >
> >
> > Em sáb, 22 de out de 2016 às 16:19, Andrew Fish <afish@apple.com>
> > escreveu:
> >
> > On Oct 22, 2016, at 10:03 AM, Marvin H?user <Marvin.Haeuser@outlook.com>
> > wrote:
> >
> > Hey Rafael,
> >
> > There actually is some generic SEC code in UefiCpuPkg you might want to
> > take a look at. It's generic because it does not have "Intel NDA" code,
> > such as CAR (Cache-As-RAM) etc.
> > The Reset Vector may or may not be part of SecCore. It's either embedded
> > within the SecCore module, or a separate file in the FFS. You can check the
> > start/end address of the modules (e.g. with UEFITool) and find the Reset
> > Vector file that way.
> >
> >
> > Rafael,
> >
> > There is some strange construction things going on with the SEC for X86.
> >
> > If you look in the FDF file you will see that the SEC is a PE/COFF (or TE)
> > image and a raw binary for the 16-bit real mode reset vector code.
> >
> >
> >
> >
> https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L876
> > [Rule.Common.SEC]
> > FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
> > PE32 PE32 Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
> > RAW BIN Align = 16 |.com
> > }
> >
> > The .com files are constructed from *.nasmb, *.asm16, or *.S16 files.
> > https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32
> >
> > Special extensions are needed to have special build rules. The build rules
> > are here:
> >
> >
> >
> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template#L480
> > Look at the [Masm16-Code-File] and [Nasm-to-Binary-Code-File] rules.
> >
> > The build tools also do some magic to stitch the .com and PE/COFF (TE)
> > file together.
> >
> >
> >
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb#
> L46
> > ;
> > ; Pointer to the entry point of the PEI core
> > ; It is located at 0xFFFFFFE0, and is fixed up by some build tool
> > ; So if the value 8..1 appears in the final FD image, tool failure occurs.
> > ;
> > PeiCoreEntryPoint: DD 87654321h
> >
> >
> > The reason you need special build rules is it is really hard to get code
> > at the end of a PE/COFF file, so you need a stripped binary for the reset
> > vector.
> >
> > The next problem is how do you get the FV File to be at the end of the FV
> > (that is usually free space). The PI spec defines that if an FFS file has
> > the File GUID of gEfiFirmwareVolumeTopFileGuid then it gets place at the
> > end of the FV. Thus the X86 SEC must have this file guid. This also
> > triggers the magic behavior to stitch the .com and PE/COFF together.
> >
> >
> > https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.inf#L25
> > FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
> >
> >
> >
> > For ARM things are much simpler. The FV reserves 16-bytes at the start of
> > the volume for the reset vector. If the build tools see an FV has an ARM
> > SEC it can patch in a branch to the SEC PE/COFF (TE) entry point (going
> > from memory hopefully I did not botch that).
> >
> >
> >
> >
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L1
> 10
> > ///
> > /// The first 16 bytes are reserved to allow for the reset vector of
> > /// processors whose reset vector is at address 0.
> > ///
> > UINT8 ZeroVector[16];
> >
> >
> >
> > PS.: Seems like inline images are not supported by the mailing list (or is
> > it my error?). Either way, I do not see the image in my mail client
> > (Outlook 2016).
> >
> >
> > I don't see the image in my macOS Mail client.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> >
> > Regards,
> > Marvin.
> >
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
> > <edk2-devel-bounces@lists.01.org>] On Behalf Of
> > Rafael Machado
> > Sent: Saturday, October 22, 2016 6:28 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] Sec and Reset vector
> >
> > Hi eveyrone
> >
> > I'm doing some studies on edk2 and coreboot, but I'm having some questions
> > that I believe you can help.
> >
> > On the journey to try to understand things since the beginning, so they
> > make
> > sense in future, I'm trying to understand how does the Initial phases of
> > UEFI
> > / PI firmware work. To do that I got a bios image and start to reverse it
> > to
> > check the modules and everything present at that bios. Now I understand, at
> > least the basics, about DXE and PEI phase.
> >
> > The main question that I have now is about the SEC phase.
> > To try to understand the SEC phase I tried to reverse this firmware so I
> > could
> > check the reset vector's first jump or something like that.
> > The surprise I have is that I was not able to find this code.
> >
> > To be sure I was reversing on the correct way I generated a coreboot image.
> > On the image below we can see the initial code of a firmware generated
> > using coreboot
> >
> > [image: pasted1]
> >
> > But at the UEFI firmware I'm studying I'm not able to find anything
> > similar to
> > that.
> > My guess before starting this was that at least the SEC initial code
> > should be
> > similar to the legacy way of doing things, a jmp at 0xfff:fff0 and after
> > that the
> > magic should get started with all uefi phases.
> >
> > Could someone please give me some light on that?
> >
> >
> > Thanks and Regards
> > Rafael R. Machado
> > _______________________________________________
> > 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
> >
> >
> > _______________________________________________
> > 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: Sec and Reset vector

[Rafael Machado]

All the answers were really detailed and I agree with Andrew. These answers
are a great help when we are learning.

Thanks a lot guys. I learn a lot with this community.

Thanks and regards
Rafael

Em sex, 4 de nov de 2016 19:28, Kinney, Michael D <
michael.d.kinney@intel.com> escreveu:

> Rafael,
>
> The first instruction executed for IA32 SEC phase is typically 16-bytes
> from
> the end of the Firmware Device (FD) image generated by a build.
>
> If you look at QuarkPlatformPkg/Quark.dsc as an example build, it generates
> an 8MB  file called Quark.FD.  The reset vector is 16-bytes from the end of
> that file.  The reset vector and rest of SEC code are all in a special FFS
> file
> known at the Volume Top File(VFT).
>
> The source code for the reset vector is in the file:
>
>         UefiCpuPkg/SecCore/Ia32/ResetVector.nasmb
>
> This source file contains the code that fills the last 0x40 bytes of the
> VTF
> which is also the last 0x40 bytes of Quark.FD.
>
> The build tools do some special fixups on this file, so 16-bit relative JMP
> instruction at line 79 is fixed up to jump to the symbol _ModuleEntryPoint.
>
>         ResetHandler:
>             nop
>             nop
>         ApStartup:
>             ;
>             ; Jmp Rel16 instruction
>             ; Use machine code directly in case of the assembler
> optimization
>             ; SEC entry point relative address will be fixed up by some
> build tool.
>             ;
>             ; Typically, SEC entry point is the function
> _ModuleEntryPoint() defined in
>             ; SecEntry.asm
>             ;
>             DB      0e9h
>             DW      -3
>
> For Quark.FD, _ModuleEntryPoint is from the PlatformSecLib library at:
>
>         QuarkPlatformPkg/Library/PlatformSecLib
>
> Specifically Line l5 of the file:
>
>         QuarkPlatformPkg/Library/PlatformSecLib/Ia32/Flat32.asm
>
> _ModuleEntryEntryPoint starts in 16-bit real mode and transitions to
> 32-bit protected mode, initializes ESRAM to be used as a stack, and
> transfers control to the C function PlatformSecLibStartup() at line 220.
> The goal is to minimize the amount of assembly code and get into C code
> as quickly as possible.
>
> The PlatformSecLibStartup() function implementation is in the same
> PlatformSecLib library at line 68 of the file:
>
>         QuarkPlatformPkg/Library/PlatformSecLib/PlatformSecLib.c
>
> Best regards,
>
> Mike
>
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Rafael Machado
> > Sent: Friday, November 4, 2016 12:34 PM
> > To: Andrew Fish <afish@apple.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] Sec and Reset vector
> >
> > Hi Andrew
> >
> > Maybe my question was not clear.
> > But thanks for the information you provided.
> >
> > I think we can simplify what I need based on your last comment. You told:
> >
> > *"The .com file contains the hardware real mode reset vector
> (0xFFFFFFF0).
> > So execution starts up high. The 1st far jmp you do gets you running in
> the
> > 0x000F**** range (the ROM is aliased to the old PC address)"*
> >
> > How could I find the .com file inside the dump of a bios (I have used
> > DediProg to get the dump)?
> > I'm hunting the first far jump the firmware has.
> >
> > Thanks
> > Rafael
> >
> > Em sex, 4 de nov de 2016 às 16:50, Andrew Fish <afish@apple.com>
> escreveu:
> >
> > > On Nov 4, 2016, at 10:48 AM, Rafael Machado <
> > > rafaelrodrigues.machado@gmail.com> wrote:
> > >
> > > Hi everyone
> > >
> > > Thanks Andrew and Marvin for the clarification.
> > > Now things start to make sense.
> > >
> > > But I was still not able to understand were things start on a real
> binary
> > >
> > >
> > > Rafeal,
> > >
> > > I'm not sure what you are asking?
> > >
> > > The .com file contains the hardware real mode reset vector
> (0xFFFFFFF0).
> > > So execution starts up high. The 1st far jmp you do gets you running
> in the
> > > 0x000F**** range (the ROM is aliased to the old PC address). The .com
> file
> > > is patched with the entry point of the PE/COFF (or TE) .efi and just
> jumps
> > > into that code. At some point early in the processes the code
> transitions
> > > to protected mode and starts executing up high again (only a small
> part of
> > > the ROM is aliased down low).
> > >
> > > The SEC PE/COFF  (or TE) .efi image entry point can be found in the
> > > PE/COFF (or TE) header that is part of that image. This is how the PEI
> Core
> > > passes control to PEIMs, and it is also what the PEI/DXE/SMM cores use
> to
> > > pass control to images that are loaded into memory.
> > >
> > > There is a library that given a PE/COFF or TE image will return the
> entry
> > > point.
> > >
> > >
> > >
> >
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BasePeCoffGetEntryPointL
> > ib/PeCoffGetEntryPoint.c#L44
> > > RETURN_STATUS
> > > EFIAPI
> > > PeCoffLoaderGetEntryPoint (
> > > IN VOID *Pe32Data,
> > > OUT VOID **EntryPoint
> > > )
> > > {
> > > EFI_IMAGE_DOS_HEADER *DosHdr;
> > > EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION Hdr;
> > > ASSERT (Pe32Data != NULL);
> > > ASSERT (EntryPoint != NULL);
> > > DosHdr = (EFI_IMAGE_DOS_HEADER *)Pe32Data;
> > > if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
> > > //
> > > // DOS image header is present, so read the PE header after the DOS
> image
> > > header.
> > > //
> > > Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)((UINTN) Pe32Data + (UINTN)
> > > ((DosHdr->e_lfanew) & 0x0ffff));
> > > } else {
> > > //
> > > // DOS image header is not present, so PE header is at the image base.
> > > //
> > > Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)Pe32Data;
> > > }
> > > //
> > > // Calculate the entry point relative to the start of the image.
> > > // AddressOfEntryPoint is common for PE32 & PE32+
> > > //
> > > if (Hdr.Te->Signature == EFI_TE_IMAGE_HEADER_SIGNATURE) {
> > > *EntryPoint = (VOID *)((UINTN)Pe32Data +
> (UINTN)(Hdr.Te->AddressOfEntryPoint
> > > & 0x0ffffffff) + sizeof(EFI_TE_IMAGE_HEADER) - Hdr.Te->StrippedSize);
> > > return RETURN_SUCCESS;
> > > } else if (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE) {
> > > *EntryPoint = (VOID *)((UINTN)Pe32Data +
> (UINTN)(Hdr.Pe32->OptionalHeader.
> > > AddressOfEntryPoint & 0x0ffffffff));
> > > return RETURN_SUCCESS;
> > > }
> > > return RETURN_UNSUPPORTED;
> > > }
> > >
> > >
> > > Thanks,
> > >
> > > Andrew Fish
> > >
> > > On the attached image ResetVectorCoreboot.png we have the entry point
> on a
> > > coreboot image.
> > > What I would like to do is to find something similar to this on a UEFI
> Bios
> > > image.
> > >
> > > Based on Marvin's idea, I got the UEFI Tool and star to check the
> image I
> > > have.
> > > On the attached image TopFileInfo.png we can see to Top File mentioned
> by
> > > Andrew.
> > > The details about the Top File are these:
> > >
> > >  Offset: FF8018h
> > >
> > >  File GUID: 1BA0062E-C779-4582-8566-336AE8F78F09
> > >
> > >  Type: 03h
> > >
> > >  Attributes: 08h
> > >
> > >  Full size: 7FE8h (32744)
> > >
> > >  Header size: 18h (24)
> > >
> > >  Body size: 7FD0h (32720)
> > >
> > >  Tail size: 0h (0)
> > >
> > >  State: F8h
> > >
> > >  Header checksum: 99h, valid
> > >
> > >  Data checksum: AAh, valid
> > >
> > >  Header memory address: FFFF8018h
> > >
> > >  Data memory address: FFFF8030h
> > >
> > >  Compressed: No
> > >
> > >  Fixed: No
> > >
> > >
> > > I tried to find something similar to what I see at the coreboot image,
> but
> > > didn't find anything. Neither on the PE Image section, not on the Raw
> image
> > > sections.
> > >
> > >
> > > Any idea about how could I find the entry point of sec in this case?
> > >
> > > Thanks and Regards
> > > Rafael R. Machado
> > >
> > >
> > > Em sáb, 22 de out de 2016 às 16:19, Andrew Fish <afish@apple.com>
> > > escreveu:
> > >
> > > On Oct 22, 2016, at 10:03 AM, Marvin H?user <
> Marvin.Haeuser@outlook.com>
> > > wrote:
> > >
> > > Hey Rafael,
> > >
> > > There actually is some generic SEC code in UefiCpuPkg you might want to
> > > take a look at. It's generic because it does not have "Intel NDA" code,
> > > such as CAR (Cache-As-RAM) etc.
> > > The Reset Vector may or may not be part of SecCore. It's either
> embedded
> > > within the SecCore module, or a separate file in the FFS. You can
> check the
> > > start/end address of the modules (e.g. with UEFITool) and find the
> Reset
> > > Vector file that way.
> > >
> > >
> > > Rafael,
> > >
> > > There is some strange construction things going on with the SEC for
> X86.
> > >
> > > If you look in the FDF file you will see that the SEC is a PE/COFF (or
> TE)
> > > image and a raw binary for the 16-bit real mode reset vector code.
> > >
> > >
> > >
> > >
> >
> https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L876
> > > [Rule.Common.SEC]
> > > FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
> > > PE32 PE32 Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
> > > RAW BIN Align = 16 |.com
> > > }
> > >
> > > The .com files are constructed from *.nasmb, *.asm16, or *.S16 files.
> > > https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32
> > >
> > > Special extensions are needed to have special build rules. The build
> rules
> > > are here:
> > >
> > >
> > >
> >
> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template#L480
> > > Look at the [Masm16-Code-File] and [Nasm-to-Binary-Code-File] rules.
> > >
> > > The build tools also do some magic to stitch the .com and PE/COFF (TE)
> > > file together.
> > >
> > >
> > >
> >
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb#
> > L46
> > > ;
> > > ; Pointer to the entry point of the PEI core
> > > ; It is located at 0xFFFFFFE0, and is fixed up by some build tool
> > > ; So if the value 8..1 appears in the final FD image, tool failure
> occurs.
> > > ;
> > > PeiCoreEntryPoint: DD 87654321h
> > >
> > >
> > > The reason you need special build rules is it is really hard to get
> code
> > > at the end of a PE/COFF file, so you need a stripped binary for the
> reset
> > > vector.
> > >
> > > The next problem is how do you get the FV File to be at the end of the
> FV
> > > (that is usually free space). The PI spec defines that if an FFS file
> has
> > > the File GUID of gEfiFirmwareVolumeTopFileGuid then it gets place at
> the
> > > end of the FV. Thus the X86 SEC must have this file guid. This also
> > > triggers the magic behavior to stitch the .com and PE/COFF together.
> > >
> > >
> > >
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.inf#L25
> > > FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
> > >
> > >
> > >
> > > For ARM things are much simpler. The FV reserves 16-bytes at the start
> of
> > > the volume for the reset vector. If the build tools see an FV has an
> ARM
> > > SEC it can patch in a branch to the SEC PE/COFF (TE) entry point (going
> > > from memory hopefully I did not botch that).
> > >
> > >
> > >
> > >
> >
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L1
> > 10
> > > ///
> > > /// The first 16 bytes are reserved to allow for the reset vector of
> > > /// processors whose reset vector is at address 0.
> > > ///
> > > UINT8 ZeroVector[16];
> > >
> > >
> > >
> > > PS.: Seems like inline images are not supported by the mailing list
> (or is
> > > it my error?). Either way, I do not see the image in my mail client
> > > (Outlook 2016).
> > >
> > >
> > > I don't see the image in my macOS Mail client.
> > >
> > > Thanks,
> > >
> > > Andrew Fish
> > >
> > >
> > > Regards,
> > > Marvin.
> > >
> > > -----Original Message-----
> > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
> > > <edk2-devel-bounces@lists.01.org>] On Behalf Of
> > > Rafael Machado
> > > Sent: Saturday, October 22, 2016 6:28 PM
> > > To: edk2-devel@lists.01.org
> > > Subject: [edk2] Sec and Reset vector
> > >
> > > Hi eveyrone
> > >
> > > I'm doing some studies on edk2 and coreboot, but I'm having some
> questions
> > > that I believe you can help.
> > >
> > > On the journey to try to understand things since the beginning, so they
> > > make
> > > sense in future, I'm trying to understand how does the Initial phases
> of
> > > UEFI
> > > / PI firmware work. To do that I got a bios image and start to reverse
> it
> > > to
> > > check the modules and everything present at that bios. Now I
> understand, at
> > > least the basics, about DXE and PEI phase.
> > >
> > > The main question that I have now is about the SEC phase.
> > > To try to understand the SEC phase I tried to reverse this firmware so
> I
> > > could
> > > check the reset vector's first jump or something like that.
> > > The surprise I have is that I was not able to find this code.
> > >
> > > To be sure I was reversing on the correct way I generated a coreboot
> image.
> > > On the image below we can see the initial code of a firmware generated
> > > using coreboot
> > >
> > > [image: pasted1]
> > >
> > > But at the UEFI firmware I'm studying I'm not able to find anything
> > > similar to
> > > that.
> > > My guess before starting this was that at least the SEC initial code
> > > should be
> > > similar to the legacy way of doing things, a jmp at 0xfff:fff0 and
> after
> > > that the
> > > magic should get started with all uefi phases.
> > >
> > > Could someone please give me some light on that?
> > >
> > >
> > > Thanks and Regards
> > > Rafael R. Machado
> > > _______________________________________________
> > > 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
> > >
> > >
> > > _______________________________________________
> > > 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: Sec and Reset vector

[Rafael Machado]

Hi guys.

This e-mail if for the future generations, and proves everything you guys
commented to guide me when I did the first question.

So if you have a uefi firmware image, and would like to check how
everything happens using radare,
you need to do the following:

step 1: Check your .bin file size (in my case the image has 16MB)
step 2: convert the image size using a calculator (16MB * 1024 * 1024 =
0x1000000 )
step 3: Since everything at the first stages of the boot happens in real
mode, the instructions are 16 bits long, so you need to go back 16 bits,
this gives you the position 0xFFFFF0. Now you are at the reset vector

At radare you can do all this using these commands:

radare2.exe mybios.bin -b 16
> s 0x1000000
> s -16
> pd 10

The attached image shows an example of the result.
Thanks everyone for the comments and tips.


Rafael R. Machado

[image: FindingTheResetVector.png]


Em sex, 4 de nov de 2016 às 20:19, Rafael Machado <
rafaelrodrigues.machado@gmail.com> escreveu:

> All the answers were really detailed and I agree with Andrew. These
> answers are a great help when we are learning.
>
> Thanks a lot guys. I learn a lot with this community.
>
> Thanks and regards
>
>
> Rafael
>
> Em sex, 4 de nov de 2016 19:28, Kinney, Michael D <
> michael.d.kinney@intel.com> escreveu:
>
> Rafael,
>
> The first instruction executed for IA32 SEC phase is typically 16-bytes
> from
> the end of the Firmware Device (FD) image generated by a build.
>
> If you look at QuarkPlatformPkg/Quark.dsc as an example build, it generates
> an 8MB  file called Quark.FD.  The reset vector is 16-bytes from the end of
> that file.  The reset vector and rest of SEC code are all in a special FFS
> file
> known at the Volume Top File(VFT).
>
> The source code for the reset vector is in the file:
>
>         UefiCpuPkg/SecCore/Ia32/ResetVector.nasmb
>
> This source file contains the code that fills the last 0x40 bytes of the
> VTF
> which is also the last 0x40 bytes of Quark.FD.
>
> The build tools do some special fixups on this file, so 16-bit relative JMP
> instruction at line 79 is fixed up to jump to the symbol _ModuleEntryPoint.
>
>         ResetHandler:
>             nop
>             nop
>         ApStartup:
>             ;
>             ; Jmp Rel16 instruction
>             ; Use machine code directly in case of the assembler
> optimization
>             ; SEC entry point relative address will be fixed up by some
> build tool.
>             ;
>             ; Typically, SEC entry point is the function
> _ModuleEntryPoint() defined in
>             ; SecEntry.asm
>             ;
>             DB      0e9h
>             DW      -3
>
> For Quark.FD, _ModuleEntryPoint is from the PlatformSecLib library at:
>
>         QuarkPlatformPkg/Library/PlatformSecLib
>
> Specifically Line l5 of the file:
>
>         QuarkPlatformPkg/Library/PlatformSecLib/Ia32/Flat32.asm
>
> _ModuleEntryEntryPoint starts in 16-bit real mode and transitions to
> 32-bit protected mode, initializes ESRAM to be used as a stack, and
> transfers control to the C function PlatformSecLibStartup() at line 220.
> The goal is to minimize the amount of assembly code and get into C code
> as quickly as possible.
>
> The PlatformSecLibStartup() function implementation is in the same
> PlatformSecLib library at line 68 of the file:
>
>         QuarkPlatformPkg/Library/PlatformSecLib/PlatformSecLib.c
>
> Best regards,
>
> Mike
>
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Rafael Machado
> > Sent: Friday, November 4, 2016 12:34 PM
> > To: Andrew Fish <afish@apple.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] Sec and Reset vector
> >
> > Hi Andrew
> >
> > Maybe my question was not clear.
> > But thanks for the information you provided.
> >
> > I think we can simplify what I need based on your last comment. You told:
> >
> > *"The .com file contains the hardware real mode reset vector
> (0xFFFFFFF0).
> > So execution starts up high. The 1st far jmp you do gets you running in
> the
> > 0x000F**** range (the ROM is aliased to the old PC address)"*
> >
> > How could I find the .com file inside the dump of a bios (I have used
> > DediProg to get the dump)?
> > I'm hunting the first far jump the firmware has.
> >
> > Thanks
> > Rafael
> >
> > Em sex, 4 de nov de 2016 às 16:50, Andrew Fish <afish@apple.com>
> escreveu:
> >
> > > On Nov 4, 2016, at 10:48 AM, Rafael Machado <
> > > rafaelrodrigues.machado@gmail.com> wrote:
> > >
> > > Hi everyone
> > >
> > > Thanks Andrew and Marvin for the clarification.
> > > Now things start to make sense.
> > >
> > > But I was still not able to understand were things start on a real
> binary
> > >
> > >
> > > Rafeal,
> > >
> > > I'm not sure what you are asking?
> > >
> > > The .com file contains the hardware real mode reset vector
> (0xFFFFFFF0).
> > > So execution starts up high. The 1st far jmp you do gets you running
> in the
> > > 0x000F**** range (the ROM is aliased to the old PC address). The .com
> file
> > > is patched with the entry point of the PE/COFF (or TE) .efi and just
> jumps
> > > into that code. At some point early in the processes the code
> transitions
> > > to protected mode and starts executing up high again (only a small
> part of
> > > the ROM is aliased down low).
> > >
> > > The SEC PE/COFF  (or TE) .efi image entry point can be found in the
> > > PE/COFF (or TE) header that is part of that image. This is how the PEI
> Core
> > > passes control to PEIMs, and it is also what the PEI/DXE/SMM cores use
> to
> > > pass control to images that are loaded into memory.
> > >
> > > There is a library that given a PE/COFF or TE image will return the
> entry
> > > point.
> > >
> > >
> > >
> >
> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BasePeCoffGetEntryPointL
> > ib/PeCoffGetEntryPoint.c#L44
> > > RETURN_STATUS
> > > EFIAPI
> > > PeCoffLoaderGetEntryPoint (
> > > IN VOID *Pe32Data,
> > > OUT VOID **EntryPoint
> > > )
> > > {
> > > EFI_IMAGE_DOS_HEADER *DosHdr;
> > > EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION Hdr;
> > > ASSERT (Pe32Data != NULL);
> > > ASSERT (EntryPoint != NULL);
> > > DosHdr = (EFI_IMAGE_DOS_HEADER *)Pe32Data;
> > > if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
> > > //
> > > // DOS image header is present, so read the PE header after the DOS
> image
> > > header.
> > > //
> > > Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)((UINTN) Pe32Data + (UINTN)
> > > ((DosHdr->e_lfanew) & 0x0ffff));
> > > } else {
> > > //
> > > // DOS image header is not present, so PE header is at the image base.
> > > //
> > > Hdr.Pe32 = (EFI_IMAGE_NT_HEADERS32 *)Pe32Data;
> > > }
> > > //
> > > // Calculate the entry point relative to the start of the image.
> > > // AddressOfEntryPoint is common for PE32 & PE32+
> > > //
> > > if (Hdr.Te->Signature == EFI_TE_IMAGE_HEADER_SIGNATURE) {
> > > *EntryPoint = (VOID *)((UINTN)Pe32Data +
> (UINTN)(Hdr.Te->AddressOfEntryPoint
> > > & 0x0ffffffff) + sizeof(EFI_TE_IMAGE_HEADER) - Hdr.Te->StrippedSize);
> > > return RETURN_SUCCESS;
> > > } else if (Hdr.Pe32->Signature == EFI_IMAGE_NT_SIGNATURE) {
> > > *EntryPoint = (VOID *)((UINTN)Pe32Data +
> (UINTN)(Hdr.Pe32->OptionalHeader.
> > > AddressOfEntryPoint & 0x0ffffffff));
> > > return RETURN_SUCCESS;
> > > }
> > > return RETURN_UNSUPPORTED;
> > > }
> > >
> > >
> > > Thanks,
> > >
> > > Andrew Fish
> > >
> > > On the attached image ResetVectorCoreboot.png we have the entry point
> on a
> > > coreboot image.
> > > What I would like to do is to find something similar to this on a UEFI
> Bios
> > > image.
> > >
> > > Based on Marvin's idea, I got the UEFI Tool and star to check the
> image I
> > > have.
> > > On the attached image TopFileInfo.png we can see to Top File mentioned
> by
> > > Andrew.
> > > The details about the Top File are these:
> > >
> > >  Offset: FF8018h
> > >
> > >  File GUID: 1BA0062E-C779-4582-8566-336AE8F78F09
> > >
> > >  Type: 03h
> > >
> > >  Attributes: 08h
> > >
> > >  Full size: 7FE8h (32744)
> > >
> > >  Header size: 18h (24)
> > >
> > >  Body size: 7FD0h (32720)
> > >
> > >  Tail size: 0h (0)
> > >
> > >  State: F8h
> > >
> > >  Header checksum: 99h, valid
> > >
> > >  Data checksum: AAh, valid
> > >
> > >  Header memory address: FFFF8018h
> > >
> > >  Data memory address: FFFF8030h
> > >
> > >  Compressed: No
> > >
> > >  Fixed: No
> > >
> > >
> > > I tried to find something similar to what I see at the coreboot image,
> but
> > > didn't find anything. Neither on the PE Image section, not on the Raw
> image
> > > sections.
> > >
> > >
> > > Any idea about how could I find the entry point of sec in this case?
> > >
> > > Thanks and Regards
> > > Rafael R. Machado
> > >
> > >
> > > Em sáb, 22 de out de 2016 às 16:19, Andrew Fish <afish@apple.com>
> > > escreveu:
> > >
> > > On Oct 22, 2016, at 10:03 AM, Marvin H?user <
> Marvin.Haeuser@outlook.com>
> > > wrote:
> > >
> > > Hey Rafael,
> > >
> > > There actually is some generic SEC code in UefiCpuPkg you might want to
> > > take a look at. It's generic because it does not have "Intel NDA" code,
> > > such as CAR (Cache-As-RAM) etc.
> > > The Reset Vector may or may not be part of SecCore. It's either
> embedded
> > > within the SecCore module, or a separate file in the FFS. You can
> check the
> > > start/end address of the modules (e.g. with UEFITool) and find the
> Reset
> > > Vector file that way.
> > >
> > >
> > > Rafael,
> > >
> > > There is some strange construction things going on with the SEC for
> X86.
> > >
> > > If you look in the FDF file you will see that the SEC is a PE/COFF (or
> TE)
> > > image and a raw binary for the 16-bit real mode reset vector code.
> > >
> > >
> > >
> > >
> >
> https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPkg.fdf#L876
> > > [Rule.Common.SEC]
> > > FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
> > > PE32 PE32 Align = 8 $(INF_OUTPUT)/$(MODULE_NAME).efi
> > > RAW BIN Align = 16 |.com
> > > }
> > >
> > > The .com files are constructed from *.nasmb, *.asm16, or *.S16 files.
> > > https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32
> > >
> > > Special extensions are needed to have special build rules. The build
> rules
> > > are here:
> > >
> > >
> > >
> >
> https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.template#L480
> > > Look at the [Masm16-Code-File] and [Nasm-to-Binary-Code-File] rules.
> > >
> > > The build tools also do some magic to stitch the .com and PE/COFF (TE)
> > > file together.
> > >
> > >
> > >
> >
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/ResetVec.nasmb#
> > L46
> > > ;
> > > ; Pointer to the entry point of the PEI core
> > > ; It is located at 0xFFFFFFE0, and is fixed up by some build tool
> > > ; So if the value 8..1 appears in the final FD image, tool failure
> occurs.
> > > ;
> > > PeiCoreEntryPoint: DD 87654321h
> > >
> > >
> > > The reason you need special build rules is it is really hard to get
> code
> > > at the end of a PE/COFF file, so you need a stripped binary for the
> reset
> > > vector.
> > >
> > > The next problem is how do you get the FV File to be at the end of the
> FV
> > > (that is usually free space). The PI spec defines that if an FFS file
> has
> > > the File GUID of gEfiFirmwareVolumeTopFileGuid then it gets place at
> the
> > > end of the FV. Thus the X86 SEC must have this file guid. This also
> > > triggers the magic behavior to stitch the .com and PE/COFF together.
> > >
> > >
> > >
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.inf#L25
> > > FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
> > >
> > >
> > >
> > > For ARM things are much simpler. The FV reserves 16-bytes at the start
> of
> > > the volume for the reset vector. If the build tools see an FV has an
> ARM
> > > SEC it can patch in a branch to the SEC PE/COFF (TE) entry point (going
> > > from memory hopefully I did not botch that).
> > >
> > >
> > >
> > >
> >
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L1
> > 10
> > > ///
> > > /// The first 16 bytes are reserved to allow for the reset vector of
> > > /// processors whose reset vector is at address 0.
> > > ///
> > > UINT8 ZeroVector[16];
> > >
> > >
> > >
> > > PS.: Seems like inline images are not supported by the mailing list
> (or is
> > > it my error?). Either way, I do not see the image in my mail client
> > > (Outlook 2016).
> > >
> > >
> > > I don't see the image in my macOS Mail client.
> > >
> > > Thanks,
> > >
> > > Andrew Fish
> > >
> > >
> > > Regards,
> > > Marvin.
> > >
> > > -----Original Message-----
> > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
> > > <edk2-devel-bounces@lists.01.org>] On Behalf Of
> > > Rafael Machado
> > > Sent: Saturday, October 22, 2016 6:28 PM
> > > To: edk2-devel@lists.01.org
> > > Subject: [edk2] Sec and Reset vector
> > >
> > > Hi eveyrone
> > >
> > > I'm doing some studies on edk2 and coreboot, but I'm having some
> questions
> > > that I believe you can help.
> > >
> > > On the journey to try to understand things since the beginning, so they
> > > make
> > > sense in future, I'm trying to understand how does the Initial phases
> of
> > > UEFI
> > > / PI firmware work. To do that I got a bios image and start to reverse
> it
> > > to
> > > check the modules and everything present at that bios. Now I
> understand, at
> > > least the basics, about DXE and PEI phase.
> > >
> > > The main question that I have now is about the SEC phase.
> > > To try to understand the SEC phase I tried to reverse this firmware so
> I
> > > could
> > > check the reset vector's first jump or something like that.
> > > The surprise I have is that I was not able to find this code.
> > >
> > > To be sure I was reversing on the correct way I generated a coreboot
> image.
> > > On the image below we can see the initial code of a firmware generated
> > > using coreboot
> > >
> > > [image: pasted1]
> > >
> > > But at the UEFI firmware I'm studying I'm not able to find anything
> > > similar to
> > > that.
> > > My guess before starting this was that at least the SEC initial code
> > > should be
> > > similar to the legacy way of doing things, a jmp at 0xfff:fff0 and
> after
> > > that the
> > > magic should get started with all uefi phases.
> > >
> > > Could someone please give me some light on that?
> > >
> > >
> > > Thanks and Regards
> > > Rafael R. Machado
> > > _______________________________________________
> > > 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
> > >
> > >
> > > _______________________________________________
> > > 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
>
>