From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9310481CCA for ; Fri, 4 Nov 2016 11:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1478285422; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ivfiCieRXj1K+1U+KGUHfzcto7+/6j0kVol/yjjiqNg=; b=Alc/lL1/2dEkSifATuSNUNgfrTkR1ICMqN0//iO2iFyKsN9qeqUbuOf8SqAJ/jX4 33MDnuoRzKwjAFnUtNsqmsFMRCohLHX1Pk/6LZH5BrH/MLGBjd4oGjLdVLm5hhG8 t+gyFG3Q1jumMeGXCVRQGWCVNCCPxzHP2poufaO9h8RJvXG5SvpiKXHjCZjdw20X rcfizbkXTJTpXJokLL7wvenP3BNKLLHd3yfi6nYYSb4BKB7KtHltI6Lh49zk0k1P Fj8XZgzA6cq+cdaR3m1JyEoAioi/hiH9NPZagfO6bMXDIJi1LpfUJPRpvNLFaeW8 bpQLemYOpRWVO9T0K6E9aw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 39.9C.16908.E68DC185; Fri, 4 Nov 2016 11:50:22 -0700 (PDT) X-AuditID: 11973e15-315ff7000000420c-38-581cd86e7e33 Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay6.apple.com (Apple SCV relay) with SMTP id C2.82.23613.E68DC185; Fri, 4 Nov 2016 11:50:22 -0700 (PDT) MIME-version: 1.0 Received: from [17.153.39.181] by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OG400M73SBVVEE0@nwk-mmpp-sz07.apple.com>; Fri, 04 Nov 2016 11:50:20 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: <81BB2DB8-1DE2-4BC1-8308-DD982E78331D@apple.com> Date: Fri, 04 Nov 2016 11:50:19 -0700 In-reply-to: Cc: "edk2-devel@lists.01.org" To: Rafael Machado References: X-Mailer: Apple Mail (2.3226) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUi2FAYpZt3QybC4MlyWYs9h44yW+x8OYPd gclj56y77B7ds/+xBDBFcdmkpOZklqUW6dslcGV0TJrBWrCsgaXiwoGLjA2ML3cxdzFyckgI mEi8udbF0sXIxSEksJdR4vvEv6wwif4jG9khEocYJfZ3rgLr4BUQlPgx+R5QBwcHs0CYxOJD MRA17xgletqXgNUIC4hLvDuzCcxmE1CWWDH/AztEr43Eh3WPGCFqNCQmzPzNAmKzCKhKHO7d xQgyk1MgWOL0tDiQMLOAucSMC1+YQGwRATOJvbMmQN2zmEni/p6JrCD1EgKyErN/eYHEJQRO sEk0d95hnMAoNAvJqbMQToUw1SWmTMmdBbZBW+LJuwusELaaxMLfi5iQxRcwsq1iFMpNzMzR zcwz00ssKMhJ1UvOz93ECIqF6XaiOxjPrLI6xCjAwajEw7tjmkyEEGtiWXFl7iFGaQ4WJXFe jotAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxFEd82sLOGfOCV3Pnhr99jXW6eTQIPr66w UFc78qJ5M7Nibz7L1Pm8bnzeOULHWFJE/X69dDjU+ry7gLXm6ivZIgMJ6yq2P/vL/75peSyT /vDvueQfe3tmet9Yvf16cfE2tg0rhKVUzfoXGHzj3G9/RKN5eV6dzm25SVmXnVSsxJPWrr30 9pUSS3FGoqEWc1FxIgDakejOZgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUi2FD8QTfvhkyEwesb3BZ7Dh1lttj5cga7 A5PHzll32T26Z/9jCWCK4rJJSc3JLEst0rdL4MromDSDtWBZA0vFhQMXGRsYX+5i7mLk5JAQ MJHoP7KRHcIWk7hwbz1bFyMXh5DAIUaJ/Z2rwIp4BQQlfky+x9LFyMHBLBAmsfhQDETNO0aJ nvYlYDXCAuIS785sArPZBJQlVsz/wA7RayPxYd0jRogaDYkJM3+zgNgsAqoSh3t3MYLM5BQI ljg9LQ4kzCxgLjHjwhcmEFtEwExi76wJ7BC7FjNJ3N8zkRWkXkJAVmL2L68JjAKzkFw3C+E6 CFNdYsqU3FlgQ7Ulnry7wAphq0ks/L2ICVl8ASPbKkaBotScxEozvcSCgpxUveT83E2M4JAu jNrB2LDc6hCjAAejEg/vjmkyEUKsiWXFlbnAEOJgVhLh5boKFOJNSaysSi3Kjy8qzUktPsQ4 kRHoxYnMUqLJ+cCIyyuJNzQxMTAxNjYzNjY3MaelsJI47wsfoIsE0hNLUrNTUwtSi2COYuLg lGpglHzzWoF9ZbWCu2NMxFolv1+F1/mabM+82nv7I++UON+M1msyJyvklC+y3kvoWfJxU7yl cvlkl3WMXJmsh1atcj6TXp3f72vSNXnNosff0vNebTCrc4zftqQu0PHy5SuKm5ts+ldZzVP2 2Nw+LXV648uzfBZiTxecn+0Xs0U/7uzM3JW6NryiSizFGYmGWsxFxYkA0BgkrtwCAAA= 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 18:50:20 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Nov 4, 2016, at 10:48 AM, Rafael Machado = wrote: >=20 > Hi everyone >=20 > Thanks Andrew and Marvin for the clarification. > Now things start to make sense. >=20 > But I was still not able to understand were things start on a real = binary Rafeal, I'm not sure what you are asking?=20 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.=20 There is a library that given a PE/COFF or TE image will return the = entry point.=20 = https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BasePeCoffGet= EntryPointLib/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->AddressOfEntryPoint & 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->OptionalHeader.AddressOfEntryPoint & 0x0ffffffff)); return RETURN_SUCCESS; } return RETURN_UNSUPPORTED; } Thanks, Andrew Fish =20 > 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. >=20 > 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: >=20 > Offset: FF8018h >=20 > File GUID: 1BA0062E-C779-4582-8566-336AE8F78F09 >=20 > Type: 03h >=20 > Attributes: 08h >=20 > Full size: 7FE8h (32744) >=20 > Header size: 18h (24) >=20 > Body size: 7FD0h (32720) >=20 > Tail size: 0h (0) >=20 > State: F8h >=20 > Header checksum: 99h, valid >=20 > Data checksum: AAh, valid >=20 > Header memory address: FFFF8018h >=20 > Data memory address: FFFF8030h >=20 > Compressed: No >=20 > Fixed: No >=20 >=20 > 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. >=20 >=20 > Any idea about how could I find the entry point of sec in this case? >=20 > Thanks and Regards > Rafael R. Machado >=20 >=20 > Em s=C3=A1b, 22 de out de 2016 =C3=A0s 16:19, Andrew Fish = escreveu: >=20 >> On Oct 22, 2016, at 10:03 AM, Marvin H?user = >> wrote: >>=20 >> Hey Rafael, >>=20 >> 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. >>=20 >>=20 >> Rafael, >>=20 >> There is some strange construction things going on with the SEC for = X86. >>=20 >> 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. >>=20 >>=20 >> = https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformPk= g.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 >> } >>=20 >> The .com files are constructed from *.nasmb, *.asm16, or *.S16 files. >> https://github.com/tianocore/edk2/tree/master/UefiCpuPkg/SecCore/Ia32 >>=20 >> Special extensions are needed to have special build rules. The build = rules >> are here: >>=20 >> = https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/build_rule.te= mplate#L480 >> Look at the [Masm16-Code-File] and [Nasm-to-Binary-Code-File] rules. >>=20 >> The build tools also do some magic to stitch the .com and PE/COFF = (TE) >> file together. >>=20 >> = https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/Ia32/Rese= tVec.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 >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> = https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/SecCore/SecCore.i= nf#L25 >> FILE_GUID =3D 1BA0062E-C779-4582-8566-336AE8F78F09 >>=20 >>=20 >>=20 >> 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). >>=20 >>=20 >> = https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmware= Volume.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]; >>=20 >>=20 >>=20 >> 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). >>=20 >>=20 >> I don't see the image in my macOS Mail client. >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >>=20 >> Regards, >> Marvin. >>=20 >> -----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 >>=20 >> Hi eveyrone >>=20 >> I'm doing some studies on edk2 and coreboot, but I'm having some = questions >> that I believe you can help. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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 >>=20 >> [image: pasted1] >>=20 >> 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. >>=20 >> Could someone please give me some light on that? >>=20 >>=20 >> Thanks and Regards >> Rafael R. Machado >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >>=20 >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >>=20 >>=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel