From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 0182E81CDC for ; Fri, 4 Nov 2016 10:48:23 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id o68so106578983qkf.3 for ; Fri, 04 Nov 2016 10:48:26 -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=ugUpIIwP4t+VeoxdyKEC9acexhex9FIuTPYvGCucvOQ=; b=a5eAHwO1LFLrCHRWl2DaSGHOibvDwRidtSU2TamLtNjTT/K42gyKTa8iK6AEG9gBGS gS7owKmIkV5X/mDQ0m54UZfrXTNDE6862aUaVm7rWQlloSbaOIRbkonshvpsCGnPA0ju D+6GJRr3Hx68C+yeVXrr1UgD9IXemnRBH2eKgBvJCTc5Y7mbrWLai7bOPSkFFWYfP8kC fu83POyJSl3I1hzThAwLmM1LmpSO+GxfHVP2lJeET1+rYalm7REp779038aY5H2cvDw/ d8yAVvb0K9OQHvc+7MeyWUKSsLtK1uywEbIY2uYYBH9AJLxk3MopJEhLai03XU/Xxgyx xMGw== 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=ugUpIIwP4t+VeoxdyKEC9acexhex9FIuTPYvGCucvOQ=; b=CexqS2MWL0xwWZHjfOyEG8xWbd/rH8M5/FkYHzoygfTfwtRbq9uoe01jE4HufXLmZp LJ8AxdHJSZ7WfgC02XtlUoKj/1PaFUj9yMTwCMbZcIOi4k6f+RxLyizu0wYM/c6gjagY YrRvnokkHA1X74vbdIOOqGWJbmj9y1cTLtFJe24GYlxhvgHnJDa+azylQy48pteJJka9 EA8fko2LL7B1/RkGRNt0f1np0MZqEVMcvdx0IDSGSpqf6n0QdVv0NmxXjrS92OsRAjBm uGzwwJK+7ttV+o4z8ti5a64NMyFvbShi1AHA1F3v3iUHY7AKS6Tib5dIQ7WYtmfZxHDB 4y6w== X-Gm-Message-State: ABUngveb87XeBYud/+MmBuyKFOEfjpqBDIsko/njt1VFhhECBabcRjL+x69bfYVs6+iVhsWfuG0K/8fPos2anw== X-Received: by 10.55.81.8 with SMTP id f8mr13944809qkb.101.1478281705208; Fri, 04 Nov 2016 10:48:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rafael Machado Date: Fri, 04 Nov 2016 17:48:13 +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:48:24 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=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 > >