From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A03C081CDC for ; Fri, 4 Nov 2016 10:50:56 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id o68so106671938qkf.3 for ; Fri, 04 Nov 2016 10:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9uMkWIkun0fy8+5kD4CHhrMdzU2fnKRrnd13CARu7WU=; b=ZDKw0RzdHoUnFKAmi2HC8h+oJNdroIRw0GvLR+QC0alPDIua9AsG22ecgiiz3oUg24 /0p88J8bnwA6c/OxNwNV8EpjBUyFxXi8hbSVpIS15THIJorNjf2L5Hbp4pQOCftSRmZh rHGFhC25oZyckEtp2qzmDzcth0UObvaIxUO6QGL70KVOErSdn8bE+mC2yVTifTQMsQt1 aXXO+Kp0vLyoh+T5B9QZkx4oWFztGX8NlS5739ABrWAG8eweQj8KWOwObX2geJcaXv6u TPAEWiZRyIcCCsU0yt0ozUCc0JqB9mdlGCZC11zpTz5zXJyPjwnMW44rBmEK7oO2qxe+ BdQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9uMkWIkun0fy8+5kD4CHhrMdzU2fnKRrnd13CARu7WU=; b=OpmNAZ2eUXCr4nFLRtRVTGNe4ca3u5dhoemrKcS8JQ68fEYb/Hg1zyrIC8Og4rNKn1 +AdUusZ0JuG7Spv1/kvCdVWYt6H6vZ/SIPq3KiC3VAmEjkukiNSIiEKkz4ce9tWIAy1N wRhUos/Er1qvyKZ4TL0bg0UFwvVuJLiVtvxKYefPYkKSbkl+V2PXpNvSnjkajJ7wuo4Q /ntLo84O4DQwvCID3+8PAeu3Rrncmvi79aokze8pf1hrE9pCk+YhgLveCentwAUh9uy6 iAEZWxsoiGxqid+erpObHuZ7bAISJG3d40W4NxRcZAxlWtTKSuLWKxvSaOo2JK9c76YY waGw== X-Gm-Message-State: ABUngvd5/PO0apf8fTjynelTOiNUli/AmmESbcm4oAKKDVQpakyN4fk2fVNxPHaaXzOzBI1NbCv6350QKjZxtA== X-Received: by 10.55.153.6 with SMTP id b6mr15978816qke.135.1478281857967; Fri, 04 Nov 2016 10:50:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rafael Machado Date: Fri, 04 Nov 2016 17:50:47 +0000 Message-ID: To: Andrew Fish Cc: "edk2-devel@lists.01.org" X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: Sec and Reset vector X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 17:50:57 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =C3=A0s 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, bu= t > didn't find anything. Neither on the PE Image section, not on the Raw ima= ge > sections. > > > Any idea about how could I find the entry point of sec in this case? > > Thanks and Regards > Rafael R. Machado > > > Em s=C3=A1b, 22 de out de 2016 =C3=A0s 16:19, Andrew Fish > escreveu: > > On Oct 22, 2016, at 10:03 AM, Marvin H?user > 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 t= he > 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/PlatformP= kg.fdf#L876 > [Rule.Common.SEC] > FILE SEC =3D $(NAMED_GUID) RELOCS_STRIPPED { > PE32 PE32 Align =3D 8 $(INF_OUTPUT)/$(MODULE_NAME).efi > RAW BIN Align =3D 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 rule= s > are here: > > https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.t= emplate#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/Res= etVec.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 =3D 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/PiFirmwar= eVolume.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 i= s > 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 question= s > 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 imag= e. > 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 > >