From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 48B1681CCC for ; Fri, 4 Nov 2016 14:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1478294341; 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=yHWm2oTUzo+AQfQKk+fz0DwpTOydseUBCv4GlwL5ZC0=; b=yuYfhQ2jHDUHo41azUsWP9IPfbnUUXsOdxMQhKNlhALaYRnY20+cLvdn8RzNT97T bVF91zgYfaLzRKsh4YGUoSqDKQQCaL66wF2YZrNaoachA8onjt/3nkMyd1EWvqG3 5BYoqRLgtMTo9OUhZaP1nAIj91UhJ1btGuPEssrcnHuc3g9x05Kb0igpEPQzrI27 +AjoN4u4d6PPOjDPomC46RR6hMvZoAgoaebMfADyGTIy1wMSEr1XlpKcbgJIJppv vpQI80tPx9p6hGySC8LcmQqohMP8teERCHW+pwn/7wBklQ14+cnu6xHsEymL5bRh xO+R9QZ+P9zMdkpPEGdppA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id BE.30.18952.54BFC185; Fri, 4 Nov 2016 14:19:01 -0700 (PDT) X-AuditID: 11973e12-7490c9a000004a08-63-581cfb455840 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 7D.35.23613.44BFC185; Fri, 4 Nov 2016 14:19:01 -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 <0OG40090IZ7NB350@nwk-mmpp-sz07.apple.com>; Fri, 04 Nov 2016 14:19:00 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: <8718D4D0-174A-4EDA-B6E7-0B09ED74FC7F@apple.com> Date: Fri, 04 Nov 2016 14:18:59 -0700 In-reply-to: Cc: "edk2-devel@lists.01.org" , Jordan Justen , Laszlo Ersek To: Rafael Machado References: <81BB2DB8-1DE2-4BC1-8308-DD982E78331D@apple.com> X-Mailer: Apple Mail (2.3226) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUi2FAYpev6WybCYNEFPot1e76xW+y41s9i sezYDhaLnS9nsDuweOycdZfdY/Gel0weky48ZvZ4v+8qWwBLFJdNSmpOZllqkb5dAlfG708+ BTu3MlUsvX6XpYHxYxtTFyMnh4SAicSk9Y3sILaQwF5GiXfL7WHiM6afYOti5AKKH2KUeH38 AgtIgldAUOLH5HtgNrNAmERD5zuooneMEv9OXGAGSQgLiEu8O7MJzGYTUJZYMf8DO0SzjcSH LZ9ZIWo0JCbM/A02iEVAVWLiywVA9RwcnAJ2EhNeBIHMZBZoZZSYs/QbWK+IgJnE3lkT2CGW XWSWmLLgPxNIg4SArMTsX14gcQmB52wSbZ0nWSYwCs1CcuwsJMfOAmphFlCXmDIlFyKsLfHk 3QVWCFtNYuHvRUzI4gsY2VYxCuUmZuboZuaZ6CUWFOSk6iXn525iBEXNdDuhHYynVlkdYhTg YFTi4d0xTSZCiDWxrLgy9xCjNAeLkjgv50WgkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsb6 hVUXNr/T26/A3CvyqOvjcy+x08VVgXNeyTB2xLb5q7Svuf156eyEu0wTq5IeSp1Rvrtj7dz5 R3ef/CEhfi3+jtecM3u5L6yv2jC/eCnrw6S364MePJTctFEj953iPHnbZKllHjEu02brVfKo TF/wlMWy/+8BbeVVrxvlA7L13y1Y8CH585kQJZbijERDLeai4kQAulikQXsCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUi2FD8Qdf1t0yEwS0ni3V7vrFb7LjWz2Kx 7NgOFoudL2ewO7B47Jx1l91j8Z6XTB6TLjxm9ni/7ypbAEsUl01Kak5mWWqRvl0CV8bvTz4F O7cyVSy9fpelgfFjG1MXIyeHhICJxIzpJ9ggbDGJC/fWA9lcHEIChxglXh+/wAKS4BUQlPgx +R6YzSwQJtHQ+Q6q6B2jxL8TF5hBEsIC4hLvzmwCs9kElCVWzP/ADtFsI/Fhy2dWiBoNiQkz f4MNYhFQlZj4cgFQPQcHp4CdxIQXQSAzmQVaGSXmLP0G1isiYCaxd9YEdohlF5klpiz4zwTS ICEgKzH7l9cERoFZSO6bheS+WUBVzALqElOm5EKEtSWevLvACmGrSSz8vYgJWXwBI9sqRoGi 1JzESjO9xIKCnFS95PzcTYzg4C+M2sHYsNzqEKMAB6MSD++OaTIRQqyJZcWVucBA4mBWEuGd /gsoxJuSWFmVWpQfX1Sak1p8iHEiI9CTE5mlRJPzgbGZVxJvaGJiYGJsbGZsbG5iTkthJXHe Fz5AFwmkJ5akZqemFqQWwRzFxMEp1cA4t+Dju39b3c4V7dAI/KP0saBsIfvi1ykXH+7M33Xc 92C/+itbK8M7Nhmtn6bptZveNYxQifE811PfyPftzPotPzSXWm3qUZ26TLn4w+K1Oly6WknW 9yflXH5+X0Nt7VHbIvN/045V9c/42ikp0b/rxbfTBZ491TsqwjXjr9ZdaHFpjFow4UaiEktx RqKhFnNRcSIAd+SVj/ECAAA= 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 21:18:59 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Nov 4, 2016, at 12:59 PM, Laszlo Ersek wrote: >=20 > On 11/04/16 20:33, Rafael Machado wrote: >> Hi Andrew >>=20 >> Maybe my question was not clear. >> But thanks for the information you provided. >>=20 >> I think we can simplify what I need based on your last comment. You = told: >>=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)"* >>=20 >> How could I find the .com file inside the dump of a bios (I have used >> DediProg to get the dump)? Rafael, Just dump the FV. The edk2 has the VolInfo command and you can pass = --offset OFFSET. There are other fancier GUI tools around, but I've = never used them. There is a signature in the FV Header that you should = be able to find and use to figure out the start of the FVs in your = extracted FD. The FV with the SEC will look something like: FV Header FV Block Map FFS File 1 FFS File 2 ..... FFS File N-1 Pad File FFS File N The FFS File N will have the VolumeTop GUID for the FFS filename.=20 An FFS file looks like: FFS Header Section 1 Header Section 1 Data Section 2 Header Section 2 Data In our case Section 1 is the SEC .efi and Section 2 is the .com file.=20 The FV layout is defined in the PI Specs and all the definitions are in = the MdePkg.=20 >> I'm hunting the first far jump the firmware has. >=20 Well the 1st instruction is real mode and 16 bytes from the end of the = ROM. You can start disassembling there and follow the code? While the = code is still in real mode you can assume the last 64K of the ROM image = is mapped to 0x000F0000, when you transition to protected mode then that = last 64K is going to map to 0xFFFF0000, also it could be bigger than = 64K.=20 > (I have zero context, but that shan't prevent me from butting in:) >=20 Likewise! I'm sure some of those playing at home have a better = understanding of how the SEC is constructed after this thread so a good = answer to the wrong question does not always go unused.=20 Thanks, Andrew Fish > it's called VTF (volume top file), and (I think) it should be at the > very end of the stuff that you dumped from the flash chip. That's how > the relevant contents show up just below 4GB, I presume. >=20 > Laszlo >=20 >>=20 >> Thanks >> Rafael >>=20 >> Em sex, 4 de nov de 2016 =C3=A0s 16:50, Andrew Fish = escreveu: >>=20 >>> On Nov 4, 2016, at 10:48 AM, Rafael Machado < >>> rafaelrodrigues.machado@gmail.com> 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 >>>=20 >>>=20 >>> Rafeal, >>>=20 >>> 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). >>>=20 >>> 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 >>>=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; >>> } >>>=20 >>>=20 >>> Thanks, >>>=20 >>> 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 >>>=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 >>>=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 >>>=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 >>>=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 >>>=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 >>>=20 >>>=20 >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel =