From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 CD25D81CDC for ; Fri, 4 Nov 2016 12:33:55 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id q130so110538115qke.1 for ; Fri, 04 Nov 2016 12:33: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=FeI9OkBEh1Um91PlanCbvDTpxcjMRoc7vUGSR71W+ts=; b=y8VCijdgbX8LlAbABC9N/3quaVzJpvhgJgTzMBaAo6GpVBSCWx1Ha1rNeJvhUsS4Zz aXjDms+YoDVSRbsqe1I5UDm4TrxQZWgiy5cCqysXmmbeD05ldmfLwsNFyT31uXR1Ms9Z 2afdtdJiVRicW6+YQKWcwq7wWzUpaEUh0LL3H2jL/wjlZIcBY7kjAp7CV1AtO4Q0S2Pm k74B2EYWBS+gTc0zW2ZQuTAWhaEz+rz8jiN6QaQ2ncjW0lDXjJP0gcZtuibeYz3KpawS NoJFruUITzqQd1SZahU5fuuE+bihOObOqC1ZDcv303l7TzxyTiP5zLJzDnpl+YoFdNIY WdCA== 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=FeI9OkBEh1Um91PlanCbvDTpxcjMRoc7vUGSR71W+ts=; b=lve0Otq9vjl2fVTbKvsm2dcnolsKLK7x6Tb6LdMaxmknxomLqw2eDEurkI6FaLTusl 3LHikbmNbKveMd+uYIRV/DjSlT2Mxu1Yujxb7aQap/eV0x9UqO6fJGBXY5zXQeHKWgeT vHMBAtVnLvjJUNiICh4xhuMxgLwZlTRMOyDzgVtcRSg5P6iKkZaR7yN49kBJ1yq7nXVN ym0UPE81u3S3m7aMt/plgYt/5P8N0B4AV1JSKOyqpBQomI9i8ujjWgASyH6eNydapEay kk9M7QTjWKUBMDltIYC7FFt/MA0lGdcTO5CkgVZh4C0sTFs6MdjUEHElYWx1088LakG3 if7g== X-Gm-Message-State: ABUngvd0k4Up46hqoi+X8NWbR5IpxyRHJdS0c0IVrAiP7I4UJoxzekJlrc9M5L85BdHUh6wiEXdRoM5IgURFOQ== X-Received: by 10.55.103.80 with SMTP id b77mr14891568qkc.142.1478288037045; Fri, 04 Nov 2016 12:33:57 -0700 (PDT) MIME-Version: 1.0 References: <81BB2DB8-1DE2-4BC1-8308-DD982E78331D@apple.com> In-Reply-To: <81BB2DB8-1DE2-4BC1-8308-DD982E78331D@apple.com> From: Rafael Machado Date: Fri, 04 Nov 2016 19:33:46 +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 19:33:56 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =C3=A0s 16:50, Andrew Fish escre= veu: > 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 t= he > 0x000F**** range (the ROM is aliased to the old PC address). The .com fil= e > is patched with the entry point of the PE/COFF (or TE) .efi and just jump= s > 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 o= f > 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 Co= re > 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/BasePeCoffGe= tEntryPointLib/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 !=3D NULL); > ASSERT (EntryPoint !=3D NULL); > DosHdr =3D (EFI_IMAGE_DOS_HEADER *)Pe32Data; > if (DosHdr->e_magic =3D=3D EFI_IMAGE_DOS_SIGNATURE) { > // > // DOS image header is present, so read the PE header after the DOS image > header. > // > Hdr.Pe32 =3D (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 =3D (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 =3D=3D EFI_TE_IMAGE_HEADER_SIGNATURE) { > *EntryPoint =3D (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Te->AddressOfEntry= Point > & 0x0ffffffff) + sizeof(EFI_TE_IMAGE_HEADER) - Hdr.Te->StrippedSize); > return RETURN_SUCCESS; > } else if (Hdr.Pe32->Signature =3D=3D EFI_IMAGE_NT_SIGNATURE) { > *EntryPoint =3D (VOID *)((UINTN)Pe32Data + (UINTN)(Hdr.Pe32->OptionalHead= er. > 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 Bi= os > 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 > > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > >