Re: Sec and Reset vector

[Rafael Machado <rafaelrodrigues.machado@gmail.com>]

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