From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 D5F371A1E31 for ; Wed, 5 Oct 2016 09:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1475686267; 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=4pdE2kNQMiWDRjgCDGPVlEi23El+y10Yg3wMmhAblyU=; b=gVdKMU8mQ6D2bjsyJ3/DYJzLnM9Z7AWM4u1QRdw8AgLepX/qUpWsznh8FaYddQQ9 ZFUKvIPyZ3oXh/rwxEEz9BHcFwbbLzDosUOGCyD8WXYQl2XC8JTBhg57unUFP6Hf INdgZRbn34RPL+L2D6IGhbIazwBn7R9TN/ghv2PdFVVfK2ogh+WDRRRU243g0sxF vYxhmDE3nkjOtznhZjEFz5MZDfvpq7yXVsBAYH+mVClnnjZqO05t0YKiayOxrLTm S1rMSkG3ip6Gn63O/l6d2VqODhce1PhrK/2YtniAaI8U01Ig2CMsTP1Sjyws5mAM WI+PO9UoX19CY/okZvGVdw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id ED.CC.07050.B7F25F75; Wed, 5 Oct 2016 09:51:07 -0700 (PDT) X-AuditID: 11973e16-e7d8d9a000001b8a-03-57f52f7baa8b Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay6.apple.com (Apple SCV relay) with SMTP id 13.8C.23613.B7F25F75; Wed, 5 Oct 2016 09:51:07 -0700 (PDT) MIME-version: 1.0 Received: from [17.153.37.250] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OEL00A262T6A520@nwk-mmpp-sz13.apple.com>; Wed, 05 Oct 2016 09:51:07 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: <68CAE063-1A6B-493B-B728-B2991F018DC6@apple.com> Date: Wed, 05 Oct 2016 09:51:06 -0700 In-reply-to: Cc: edk2-devel To: valerij zaporogeci References: X-Mailer: Apple Mail (2.3226) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUi2FAYpVut/zXcYNtaBYs9h44yWzz+187s wOSxc9Zddo/u2f9YApiiuGxSUnMyy1KL9O0SuDL6ti1hLDg+h7Fi4/3oBsb7zYxdjJwcEgIm Eq9W3WXpYuTiEBLYyyjx5d08NpjEzMYWdojEIUaJ67Pns4MkeAUEJX5MvscCYjMLhEl8nbmX DaLoHaNE+9YJrCAJYQFxiXdnNjGD2GwCyhIr5n+AaraR6H4zkxGiRkliaeM8sDiLgKpEWyfE Ak6BYInvT78yQyzQkPi6ejtYXERAR+Lg/YtgcSGBAIltD+YALeYAulRWYvYvL5AbJASOsEk0 9hxln8AoNAvJrbOQ3DoLqIVZQF1iypRciLC2xJN3F1ghbDWJhb8XMSGLL2BkW8UolJuYmaOb mWeul1hQkJOql5yfu4kRFA3T7cR2MD5cZXWIUYCDUYmH94bq13Ah1sSy4srcQ4zSHCxK4rwc Hz6HCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamA0KTnH4Rtv9m5WUZmv7RIng7Xxddbbrk5e fm8Zn2KAnKhMYFBgYZL8pJdvJh2bUct/Lup7t/XridzpMjnPmusehjv8My9/tiZ/bcf6uomW V1RfzbVMXGP67vPp4IgALY3IEO7ZyUw3VZe+YgwxnvA0W1p9ZeGE7wEvjh6/lnnNd5fge9Zt gb5KLMUZiYZazEXFiQD8poE/ZwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUi2FB8Q7da/2u4wdFr0hZ7Dh1ltnj8r53Z gclj56y77B7ds/+xBDBFcdmkpOZklqUW6dslcGX0bVvCWHB8DmPFxvvRDYz3mxm7GDk5JARM JGY2trBD2GISF+6tZ+ti5OIQEjjEKHF99nywBK+AoMSPyfdYQGxmgTCJrzP3QhW9Y5Ro3zqB FSQhLCAu8e7MJmYQm01AWWLF/A9QzTYS3W9mMkLUKEksbZwHFmcRUJVo64RYwCkQLPH96Vdm iAUaEl9XbweLiwjoSBy8fxEsLiQQILHtwRygxRxAl8pKzP7lNYFRYBaS82YhOW8WUBWzgLrE lCm5EGFtiSfvLrBC2GoSC38vYkIWX8DItopRoCg1J7HSTC+xoCAnVS85P3cTIzioC6N2MDYs tzrEKMDBqMTDe0P1a7gQa2JZcWUuMIw4mJVEeBfrAoV4UxIrq1KL8uOLSnNSiw8xTmQE+nEi s5Rocj4w5vJK4g1NTAxMjI3NjI3NTcxpKawkzrv78qdwIYH0xJLU7NTUgtQimKOYODilGhjF jvz3y33jf4VlWRT3gp2dstJ6U0M+Np16Fxb7ZyPnu0qGhQLaH4L8XnAHPH0u9Liw5rFMxrEp 6/bvuJlyx7Kc/cC8Nfu1Dr7l2uPSvi849VOqCnulgvXio/vzbS5qFdcyirRu8TlXf9z12fdn bl6zdL9aC5m9XGQZnl3Gwldr8eXE9eXyvseUWIozEg21mIuKEwGLw18v3QIAAA== X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: TE relocations 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: Wed, 05 Oct 2016 16:51:08 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Oct 5, 2016, at 8:08 AM, valerij zaporogeci = wrote: >=20 > Hi everyone. I have a problem with understanding the description of TE > files and its relocations. TE is basically PE/COFF with a smaller header. Unlike ELF (Mach-O, etc.) = PE/COFF includes the headers in the executable image. The TE header is = basically the bits required by EFI and the adjustments (so you can = calculate the location the PE/COFF header would have started, since the = sections are relative to that in the PE/COFF debug info) needed by the = debugger to turn it into a PE/COFF.=20 The only reason TE exists is to save size in the ROM for XIP code. The = build tools zero out the unused parts of the PE/COFF header so they tend = to compress well and TE is not needed.=20 > The specifications says this: > "17.2 XIP Images > For execute-in-place (XIP) images that do not require relocations, > loading a TE image simply > requires that the loader adjust the image=E2=80=99s entry point from = the value > specified in the > EFI_TE_IMAGE_HEADER. For example, if the image (and thus the TE > header) resides at memory > location LoadedImageAddress, then the actual entry for the driver is > computed as follows: > EntryPoint =3D LoadedImageAddress + sizeof (EFI_TE_IMAGE_HEADER) > + > ((EFI_TE_IMAGE_HEADER *)LoadedImageAddress)=E2=80=93> > AddressOfEntryPoint =E2=80=93 ((EFI_TE_IMAGE_HEADER *) > LoadedImageAddress)=E2=80=93>StrippedSize;" >=20 > But it looks not as simple as "simply" adjusting the only > AddressOfEntryPoint. What "do not require relocations means" here? PE/COFF images are linked at a specific address and can execute directly = if they are run from that address. If a PE/COFF image is loaded/executed = from a different address the relocations must be applied to adjust all = the absolute references in the image to the new addresses.=20 The edk2 links PE/COFF images at zero (or for things like ELF they add a = pad for the PE/COFF header ~0x220). When an FV is constructed and XIP = (SEC, PEIM, and PEI CORE) images are placed in the FV these PE/COFF = images get relocated to the address in the FV (ROM address).=20 If the code is XIP then there is no need for relocations as that code = can run from any address.=20 I think this section is making the point that even if the image does not = contain any relocations (all code is PC relative for example) you still = have to adjust the EntryPoint to point to ROM address of the entry = point.=20 > Suppose an Image has ImageBase set to X in its header, and it IS at > the address X in XIP memory. Will it need relocations? No.=20 > For PE it > won't, but it seems it is not the case for TE. Since not only > AddressOfEntryPoint is affected, also CodeBase, sections RVAs and all > base relocations too. They all are lying not at their RVA in XIP > memory, because TE has a smaller header and screws up even > FileAlignment of sections. Doesn't it? No. The TE header lets you compute the location of the PE/COFF header as = this is required to make debuggers happy. So part of the TE construction = is making sure the virtual start of the PE/COFF header is aligned = correctly. You also need to make sure that the file alignment and = section alignment are the same. For most toolchains 0x20 is uses as the = file and section alignment to save space. Note: 0x20 was picked as that was the smallest value we could get to = work with Visual Studio "back in the day." > The adjustment in the quote uses StrippedSize and it is described as > what was removed from PE: >=20 > "The StrippedSize should be set to the number of bytes removed from > the start of the original > image, which will typically include the MS-DOS, COFF, and optional > headers, as well as the section headers." >=20 > But does it take into account section alignment by FileAlignment? Yes as I pointed out section alignment and FileAlignment has to be the = same for XIP to work.=20 > (SectionAlignment=3D=3DFileAlignment in this case). Because for = example if > FileAlignment =3D 200h, then in PE, section for code would be sitting = at > n*200h from the beginning of the file and from ImageBase in XIP > memory. > Here is how specification describes PE->TE tranformation process: > "=E2=80=A2 Create an EFI_TE_IMAGE_HEADER in memory > =E2=80=A2 Parse the PE/COFF headers in an existing image and extract = the > necessary fields to fill in the EFI_TE_IMAGE_HEADER > =E2=80=A2 Fill in the signature and stripped size fields in the = EFI_TE_IMAGE_HEADER > =E2=80=A2 Write out the EFI_TE_IMAGE_HEADER to a new binary file > =E2=80=A2 Write out the contents of the original image, less the = stripped > headers, to the output file" >=20 > This process would place any section at different file offset > (dispecting alignment) than in PE, and as a result for XIP - different > RVA from ImageBase. For XIP this would mean that such a file requires > relocation, even though its actual ImageBase is exactly what is > written in the file. For non-XIP it would mean that the loader would > need section headers to know what displacement to put the section to > in memory to not break addresses. But they are stripped! Otherwise, if > it just blindly copies what is after TE header, RVAs would be broken, > all addresses would be broken, as for XIP. > In fact this means any TE file loaded at its preferred ImageBase will > need relocations. And for non-XIP. section header cannot be stripped. > Then what TE files would not need relocations? Any TE that executes from the ROM directly does not need relocations. = That is how it works today. As long as SectionAlignment =3D=3D = FileAlignment then everything works from an XIP point of view.=20 I guess we could have some bugs in the entire stack (PE/COFF -> TE -> = FV) of not honoring the original PE/COFF alignment? But as my Niece = would say Meh. The point of TE is to save space in the ROM vs. PE/COFF = so if the section alignment is 0x200 there is no point in using TE, you = should just use PE/COFF.=20 The rules in the FDF file allow you to control if XIP code is TE or = PE/COFF. It looks like different platforms pick different rules.=20 = https://github.com/tianocore/edk2/blob/master/QuarkPlatformPkg/QuarkMin.fd= f#L517 = = https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.fdf#L420 = It is also possible to control on a per module basis if an XIP image in = TE or PE/COFF using RuleOverride in the FDF.=20 Thanks, Andrew Fish PS. I was looking at the TE Image Header and I was reminded that Vincent = Zimmer used his initials for the TE signature. I'm sure Vincent will = claim this was an ode to Mark Zbikowski, since MZ is the signature in = the DOS header :).=20 = https://github.com/tianocore/edk2/blob/master/MdePkg/Include/IndustryStand= ard/PeImage.h#L719 = UINT16 Signature; ///< The signature for = TE format =3D "VZ". > Did I understand right? > Thank you for answers. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel