From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [146.101.78.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C9EA91A1E30 for ; Tue, 13 Sep 2016 08:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4Kl77b+3Gc09whzOm4fbW8a9IahsX2FIeWs5qJjuJyU=; b=QzZqYJ/pR55MPJrnqWUxv9eg7sc+GS8G88rrI2KCqflL4Orv2rd/aVij1v6o+wgtjt4yJFSfzEPHKyr+PS9my82n/vG+2RvtAptcirvBrIFSHO6PU9lsnTSJhC3SI3dxLMBDVnTtSmUU0h0aX/I9AbApMEa+1trYah/PMg7KlE8= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0179.outbound.protection.outlook.com [213.199.180.179]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-7-k1ky11MIPGa8hO-7JtngIw-1; Tue, 13 Sep 2016 16:54:55 +0100 Received: from e102648.cambridge.arm.com (217.140.96.140) by HE1PR08MB1196.eurprd08.prod.outlook.com (10.166.96.20) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Tue, 13 Sep 2016 15:54:53 +0000 Date: Tue, 13 Sep 2016 16:55:41 +0100 From: Achin Gupta To: Ard Biesheuvel CC: edk2-devel-01 Message-ID: <20160913155540.GF540@e102648.cambridge.arm.com> References: <20160913140236.GC540@e102648.cambridge.arm.com> <20160913151543.GE540@e102648.cambridge.arm.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [217.140.96.140] X-ClientProxiedBy: DB3PR05CA0018.eurprd05.prod.outlook.com (10.160.41.146) To HE1PR08MB1196.eurprd08.prod.outlook.com (10.166.96.20) X-MS-Office365-Filtering-Correlation-Id: 2249fbdc-33d3-4bff-3350-08d3dbee4d6d X-Microsoft-Exchange-Diagnostics: 1; HE1PR08MB1196; 2:yaPNpFFB+jYUzRKbEMegx3770cQzRucgRgS3gl6S14qFqNMb655mbID2B5FBZBu3hTXDsWEUtDgS/gCZswVRATnQncMxvALw6Y3I6eHJSn7ENxOb6pDo03FfHJCHXgDKueoFPi9QSC/cnnJnLyN6f6Vah1N8gbFaBK64h7gpnBEb5uQMCSoOwXhwTLHUV1k0; 3:PNDpN7DcS+KzK9za6p5iRghyTBR+jaC8Nn1+NC2FHG7T13m4/UwtS/4wqzLeZk7cd9g/qz5j8uxZcgWkJUaJCSbcy9g/agTTZwk4OHsXJ31ErvpjOP22UJvdtuyjPIUI X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR08MB1196; X-Microsoft-Exchange-Diagnostics: 1; HE1PR08MB1196; 25:ftMZiMXf0opPoGRHd3zs645YDct0DqZN6kRvSPhdvihgX+iTRh82YFhtua77Bg2Q3/L11yRZBWBqgJTuy6Z0rYP8VvMGcK4HTksJMG2Qk8GrhQmO3qsoQ39Lqo4JwKqIl4yeKRzgeZ9DVY/v9W9YXC7b/WqI/lZ5PU9nWvIOF74asBklmf62/erxviHQMJ0Sl19FMGvw8rnoUan1EK2eAilW0yqQVO49aufmxML39osuC1xQpZK98Hv2HCsu9/kLyiDXeFwQKMfZEELJ2m9urJ7Cfee+AFAdLKzJQ7yhQAbblmHBTPETAotvUK49rPVmuLcdf+LUX9YEnGQDZ4dZQWh0FR940Co9ds7dHgpjbrvsFH3k4PU5Amv1q+Fk6sdirQRxZX0fjwsi4hPnlsCcm2RgsLfJPSE6D4B4nDj4rDNg1srdKqxdyAsqSu69Q+Jjperf07MY56dj1SJWwHwB3P8srxtPj8gMCB5jbOF8+yKoBy+AKd0Q6sPahHlmMj82OHuLLdV8aHCdMXZYIzehwHeAQyT0CDjpjZPE03k04CxLc5n0ThhKSkwZPfarf9pGB5B8AZa8YBVGHF7PWWxMufPjlwm16ueNjgx07tdaVc4527GrbioUeVnEsm5yaEtXt0v8IP4iViYsn4CfrvEtkFdgC95SI9QxcIsptAK/hN5R/DpCCTOXEaPgZpTgkC9bmkMPswEVwkFPMy+52s8bXbkaz/LKXLdgTy7iBk2KFXofFcgi9kB5k8jhJ5c30CQA X-LD-Processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; HE1PR08MB1196; 31:uhVs9jiwv4S/IPUgviwr9+W5rScWm0MTC7nuz8BjEecIqB+8VMFJgvuqxKTeAktVr7ZYGI0cc59PfBgWU5ob+3XHM/iHJ+2DAmuujv0utGidDkU/LeQMG1fRdavMZo1CsIfuXo9cqN/yfuF1o/KdRAeFdZcomOZoVUclpo/D+0sKakxf1G7skYZvZvNri5N22gr8ljKxpvVF8p5MuvB+XtuVxrZOgYcie1uTBPkkwdc=; 20:/j7grffF0voYPdQ9gterXT1Y09u5m9OIL4OjW3U1+Q5pDyboU7H1+hIhZ+tEYj9OlS6vYPEqh/Jvc6Z0U7M0rwMKLvG+F9KgvCvmG1/KBLVG1rh6JHyG8ap+pOJCn+8ndzHWs9D296i9kBv4qeWpJfJI8f1lMOd7UhlT5PxKmpIR2358RW8CZfMdtG1Lcb9Z9vhoCqp+KfcY4kiJzC3+622+s09qndWiq2XCG8Ib//QMZ4Sytc38KeWpivFHMppZ; 4:k2J7BGPaIWDu1vNfNBekU45izFWoQ3aXuyQdfV/nmJ/ZOQMOLoUdqv11uc1vHChe9UZJhbCgLgl8+0uht3hht8zMV4yerWcL88BcZEbAI61TMZxYcHPT5ktPH3ipVysU0qLKJ9d99+spy+GUn5/RE7QNVc30v1L2IkmS/plDP6R+j8+Xy7kR9NuOrwx2mqfHOMU9HMFroizsN+AtJ9HXFzTGhNsgr1826sXJeaMh9JIxOrODJVFWybkbJDj3RlZPKyqRWZ9hh5Rjs70tXcAQtu4B71QMFpnOFq4o7fOHG+qCdtwhioQx7Ee+m8eLw6EliBMStP59nUKfKseH8FYQiMrpY4hVgfFrVf71neqdvtu4PKO+8Jg8mFjGF7nPF6PcsOKLvpFOwEacRVzrM3K0LlPfLfFPZbhhH7LtopYXnp5abec2Gu/olbE8mJ5k7jxKWR9hXA40f7Y9k+8wdAEK/A== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(180628864354917); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:HE1PR08MB1196; BCL:0; PCL:0; RULEID:; SRVR:HE1PR08MB1196; X-Forefront-PRVS: 0064B3273C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(7916002)(40434004)(189002)(53754006)(199003)(51914003)(24454002)(7736002)(7846002)(105586002)(50986999)(8746002)(54356999)(76176999)(305945005)(4326007)(1076002)(81166006)(68736007)(101416001)(93886004)(19580405001)(97736004)(19580395003)(83506001)(81156014)(33656002)(8676002)(106356001)(77096005)(4001350100001)(97756001)(46406003)(86362001)(5890100001)(2906002)(42186005)(2950100001)(23726003)(47776003)(50466002)(110136003)(92566002)(189998001)(5660300001)(66066001)(3846002)(6116002)(586003)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR08MB1196; H:e102648.cambridge.arm.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1PR08MB1196; 23:Y8xnYwCokleFV4zhM18CoK9xQNNbL5G3HJmd3rvQ3?= =?us-ascii?Q?FZu8qnc2Pm8pC7yclB2IH+8bVT+hFgANJA78UH5xiZZ/CXx/8ayQwR/cWXvv?= =?us-ascii?Q?lMHx/HivOA1GJXKCTTNoltu179lAXoaO4XdLio/mddP+00j3uyaK27jZothu?= =?us-ascii?Q?9lPEBKfjGM9yEgaYZBA578H0u2GHfdiXlzLQevod8q3YtCxcdP6hcWpOG3jZ?= =?us-ascii?Q?W3Go/wU8ECPW/XTba1R1jiR4NKQq2crbE1985y6qJ28zsNTQJ6m3p9plfq0n?= =?us-ascii?Q?0hHGkda+fSunmbHhrYl2ump4DZuWA6f/S7bUVbNCoesoRmgTUFQ4FIgiJUEj?= =?us-ascii?Q?uNm2o3qbCHNVfsl6YzXMri4K0ANi1006HU0CBQFTYUT5QTww5Yr2UqQcHErU?= =?us-ascii?Q?beJkDjZcT4ERgw9FVkYJ5fnmHLLdlxDmZxRsPcN2b11yASVgmTq3zLibW3wQ?= =?us-ascii?Q?YPWHOp4vpDh/Tp9H821bX/Hs/pkq196LAw+LUTxEIoc+wQuDrM0arNk5TomI?= =?us-ascii?Q?fIDsOU0E0c5Ws/q92JQ/X/3GyVWzlOuqA67yKHug+O3iaMMAzpWu0yD3Tta+?= =?us-ascii?Q?w9cpV5/Uf/98ZoO61ubXpjOkg8t/eYXirlAQchK65oIl3FO7Lp1vi2IDNw6A?= =?us-ascii?Q?eWmt2yLfcBGmLlVJpzHNTylZ213vojDck4T1XuTXPd7QGFQiJxN5npt6Fam5?= =?us-ascii?Q?2nenl/e0aBfk4V1I6xnaEuzI/gRyjll8eHVpsmy6JTzZLoVY7PU9XjH/V1zj?= =?us-ascii?Q?hYOnD8V9Y+GSUq3QDc6pz//VyFMMuKqnvijqh3eSHAhWuJfY1oQWRdzGhtQ0?= =?us-ascii?Q?mhSMKG3GmsGghXcdsycL+BSQ+WwgSm3uCgfrlI7HHG3xzWbS58ko6oQwBB3a?= =?us-ascii?Q?6chHmttEfCUfkzzzZyVNqKMjXE45n4KvFoYfJQGJbO0puqxNPuPcEfTe1jxv?= =?us-ascii?Q?F6+SER/V4toQ0bx249hx7ktqvCCKEHD0TM+O3+D9pzh+K+wZj/3XnaJ4x8Mh?= =?us-ascii?Q?Pqkpz9HyxFM5CVbi55Q5QYK2jurbELoPiQwFebsQASVkEcJfqpz7xswfRIC2?= =?us-ascii?Q?e6yPLShQeIOxZeSbq50WqCMi1Rlb5xQV8WWMFrkt2346O61mXD03MXBrGyow?= =?us-ascii?Q?x1Jcn3TU6TNd5x3Z9Rk0dQHEdmyOeJxtcdKzXXoLh4z+VyCZCyMrR1MIjDvP?= =?us-ascii?Q?O2c73yKLC4xlj80G3g+XWbRyt3NW7dRlRFKgOivY1Hi4E2rj3nq7WEiIcfpc?= =?us-ascii?Q?zrdzl/61l/yIhBrvdqV7JYGmeGD5V6E71+HDbAKHZyz2GNOchFOhImz/2Ld3?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR08MB1196; 6:fRdf+NvY45TxPoxdl1fyno4vVFmtSH3H0wxfuqyaZuoM+MDsaJ91fAVfO91dv6KcfTfQZULqAoAAHCnK2xNN2+5aPYemXLP1aWIDnuNx4jAtdsUlowh6tNX2aUQ2sEV/S8QJULWXkrZwNq+REhx5vdmgln8NVaonpecomzlQ+uCwHK8sLRjHe9/WU40+WTmhI5o5G4DRYhtUgX783Q8Zt9aqsVoI7EbCZsaqkgV6w7A7zUe67svGiNEIKxDRPoB5TkNG0HKMScQKMgad16t1jK4Ue1890F6cYodMn+ZLLqgkcXvOCGrCXPBipJwXVtrpK8xOc3NfnSUbInXqMZSySg==; 5:TY+d9p9GiC+M66g9XLfnB3Fiz0bVPuAzEGjHWlw4349LTT8oD9HLps9D7cIivG4OgmDt6oP2VWHeU6q9XXEv/cqPYOEJ7TgdEQ3CG3455jlAxh4Ag5WjTsBOfr5Y4AUtjmjLocBue2fgycDHPSR3Gw==; 24:u1APcwx99ajb2XIUE7YhkbxS3mqWcmi88igBRj5ZcdqXjKeDbEZgRtBIhvN4+5ks/1eZoUDnMJ6yvlESbYfFtXb7XKXZHRC+ZuZBzebM1iM=; 7:+OIVpirkd9RJpMZBJzaCzPs9zYJhMzU/eMM8JOdU7ZuEW7HFsHEkgpsZF2jJ7URrhtj6Wm8EnPBjOhNsryyz4YikvRxQV5kBt2e4fTIc5X48uv04pFbT5DCS8mWtbGZogBPSigqkopPQqrAFgHQ8EaMCfyJs4XDv0RGxs/0qQO25k7A3IHMhs3DWXWWs/BgQotFEqZns0YEqMibHo8jw3DVKG9IbrpU3oyDKGnacYsVzsLgw5zHvy/ZpnateHNTF SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR08MB1196; 20:TK8X3ppz7tjhhVTGjUqLEG6Zjg57iIMWT8OcBa2ZJfFrr5aB7O9RV6F2wqGxTnWpVpt1+fZviUN2WdKLEvO5gbyFz8Ws5/4gf4/7aHM8e/XUsaPFoIze7eyVBbOu1Pdagzo5OcwzWBt+dmISTWh7cR1dyhqs0KWFF4HKdJWQohc= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2016 15:54:53.4191 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB1196 X-MC-Unique: k1ky11MIPGa8hO-7JtngIw-1 Subject: Re: Relocation fixup during AARCH64 SEC PE-COFF generation? 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: Tue, 13 Sep 2016 15:55:01 -0000 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, Sep 13, 2016 at 04:25:32PM +0100, Ard Biesheuvel wrote: > On 13 September 2016 at 16:16, Achin Gupta wrote: > > On Tue, Sep 13, 2016 at 03:43:41PM +0100, Ard Biesheuvel wrote: > >> On 13 September 2016 at 15:12, Ard Biesheuvel wrote: > >> > On 13 September 2016 at 15:03, Achin Gupta wro= te: > >> >> Hi All, > >> >> > >> >> Upon entry into UEFI, the ArmPlatformPkg/PrePi/PeiUniCore.inf SEC m= odule > >> >> executes directly from within the firmware volume. The FV would typ= ically be > >> >> loaded in DRAM by ARM Trusted Firmware. The rule in ArmJuno.fdf for= SEC file > >> >> types converts a PE-COFF module into a stripped Terse executable as= follows: > >> >> > >> >> [Rule.AARCH64.SEC] > >> >> FILE SEC =3D $(NAMED_GUID) RELOCS_STRIPPED FIXED { > >> >> TE TE Align =3D Auto $(INF_OUTPUT)/$(MODULE_NA= ME).efi > >> >> } > >> >> > >> >> The GCC_ARM_AARCH64_DLINK_COMMON variable includes the "--emit-relo= cs" option > >> >> when the ELF image is generated. Since the SEC module is able to "X= IP" from the > >> >> within FV, this means that the relocations have to be fixed up at l= ink time > >> >> before the TE image is created. > >> >> > >> > > >> > Correct. GenFv relocates the image based on the runtime address of t= he > >> > firmware volume. > >> > > >> >> It seems to me that in GenFw.c, at least the static relocations are= fixed up > >> >> when an ELF image is converted to PE-COFF. Can someone confirm if I= am correct > >> >> in understanding that dynamic relocations will be left as is in the= PE-COFF > >> >> image while static relocations will be fixed up? > >> >> > >> > > >> > We usually don't emit dynamic relocations, since we are not linking > >> > shared objects. > >> > >> ... or more specifically, all absolute static relocations are > >> converted into PE/COFF base relocations, all relative static > >> relocations are validated against the PE/COFF layout (which we keep > >> 1:1 identical with the ELF section layout), and all dynamic > >> relocations are ignored. > > > > Thanks Ard. I expect the relative static relocations to be fixed by the= PE-COFF > > loader at runtime. > > > > No. The PE/COFF loader only processes base relocations, which are > essentially pointers into the image where absolute addresses are > stored, and which need to have an offset applied based on the > difference between the link time base address and the load time base > address. Like in ELF, no relative dynamic relocations exist. > > Only because of the ELF to PE/COFF conversion, we have to ensure that > any relative references are still valid after the conversion. Obviously I am not well versed with the correct terminology :( I guess we are both talking about the base relocations done in PeCoffLoaderRelocateImage() (MdePkg/Library/BasePeCoffLib/BasePeCoff.c) i.e= . the EFI_IMAGE_REL_BASED_* types defined in EfiImage.h? > > >> Note that this implies that proxy generating > >> static relocations are rejected, since --emit-relocs does not produce > >> any output for the proxies. > > > > You lost me here. What do you mean by "proxy generating static relocati= ons"? > > > > Basically, GOT based relocations that result in a GOT entry to be > emitted when linking a shared object. Since those relocations are > essentially instructions to the linker to emit such a GOT entry, the > absolute relocation itself which causes the GOT entry to hold the > correct value at runtime is not present in the object file, will hence > not be emitted by --emit-relocs, and so will not have a corresponding > PE/COFF base relocation emitted for it. This is the reason why we > currently cannot support such GOT based relocations. makes sense! Thanks for the clarification. Thanks, Achin IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.