From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 41D291A1E3B for ; Wed, 5 Oct 2016 08:09:10 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 188so108070246iti.1 for ; Wed, 05 Oct 2016 08:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=5dl7zw9v8yV5YmqunPVSs21U35sc/l45NLxbSEDZ8/I=; b=QIXb0xgJF2CKeiK0FhToXEek3t8qXlMgcKmiYAsdVE7HDQt+/8bt0qTMITwZcT+jxw yCYRMvxjntSOp/5AqOr2yH05vUs9MyXa77XttmZx+c6YYUsOHyyAaScwrL/U+eJ888BQ bRbx0WpCGXYelOY+lFqOeWGDYhtPgfzQ7fwWlQfQiY9cNm593nolDJ1RKCuucZBa24CT yRAW0MQsjk8HV9gybFO9CySPkdtCg+ST1Z2DW4l6hSDlqPDmEeLEEHXf9vJXIyfrtF2K QZ05j8x9Wfn+kFgzXKJLQQPOzSRMErwTTas52WkeD9Ik83W7cMPRVWHooFLoY5933kYT jmXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=5dl7zw9v8yV5YmqunPVSs21U35sc/l45NLxbSEDZ8/I=; b=GClTCY7ScmExasfHbq9gagfNdMabm42NbYlxFpgo7p1P+bNuUWYGLt8+sWSX3Pc8Aq NyyabUruO+OpLOLMxmdnLNIufE6nhDxMe+1CDIY+597uP7e+At05LzfLTrCHEIobkRT6 rDSrU8f3WCuauMlrkG9BOvdMlWJGNPGYxh7VdurlwLmCrC/IWKw8t8cX0jnK57g69w+U Pku2uaKDS4ey8IMZa3EhETK8xN06G0u63scQ93ADb2cNUfNdep3Sq46ejNRo+htCZAk4 J5PQHYveEu8+6ZRhowONAZClC5ogchMeBTVp5qQJxSVTy5tmCg1iiSWRJifw5m6phHIJ KIHg== X-Gm-Message-State: AA6/9RnQ16aoGHHOwNi5QPCUY3I1RdNE68wVtYppDgEmrj50HbsZkQxZcNrAbilT8LM9fYXGHzUEqcwUXfv7SQ== X-Received: by 10.107.173.136 with SMTP id m8mr10078775ioo.188.1475680133739; Wed, 05 Oct 2016 08:08:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.203.132 with HTTP; Wed, 5 Oct 2016 08:08:53 -0700 (PDT) From: valerij zaporogeci Date: Wed, 5 Oct 2016 18:08:53 +0300 Message-ID: To: edk2-devel Subject: 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 15:09:10 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi everyone. I have a problem with understanding the description of TE files and its relocations. 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 va= lue 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;" But it looks not as simple as "simply" adjusting the only AddressOfEntryPoint. What "do not require relocations means" here? 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? 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? The adjustment in the quote uses StrippedSize and it is described as what was removed from PE: "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." But does it take into account section alignment by FileAlignment? (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_IMAG= E_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" 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? Did I understand right? Thank you for answers.