From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) by mx.groups.io with SMTP id smtpd.web08.1340.1627927537805248009 for ; Mon, 02 Aug 2021 11:05:38 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=uEby8rKZ; spf=pass (domain: apple.com, ip: 17.171.2.72, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 172I362j008720; Mon, 2 Aug 2021 11:05:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=9Yu1fm6Nc1vkL5K0awpNKk5jnK6KFJoawvBd5kz30CY=; b=uEby8rKZou0wkfXH53OcWIOrwd09ebEXpQFq9im+DNXGhYKapJpdRp95IuYmXjwF3WqC g1LS9axACO4I4PPYVQliF3TlrSFJevY5UgB2u1A/2IE2VptwOVdGzXhmfzWOYRypTrYi 1uqJcaunFM5AqsBEH+2Z8PfIDkSYGyZikbbzzDZW3rxG4t1j/Rna17vRFAOT3pfheCnG NTHaCRFrfLtl0FLrFYWSB5qqk19hSnNfa8D6Lk5ZmGlUTM2pp8tg4o+iymBF9UUxBIWu uBmUVsmJ4GVjzFNeIUKsZ6vM04YLRHJ3bDJsO6K0+vgF+xa3gX9w1MwN+t1JVROwTs3G Tw== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3a55gut3qh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 02 Aug 2021 11:05:34 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QX800IFS4X9Q060@rn-mailsvcp-mta-lapp02.rno.apple.com>; Mon, 02 Aug 2021 11:05:33 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QX800P004PI3T00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 02 Aug 2021 11:05:33 -0700 (PDT) X-Va-A: X-Va-T-CD: 9ad46be6e1c3c1a24e92ea4dad46d58d X-Va-E-CD: 8dcd0bc8f52751ffdabdeee450fe4a7d X-Va-R-CD: bafe279e2433716ca8c56ae0083e7365 X-Va-CD: 0 X-Va-ID: 1289002b-3b67-45f9-b981-4ec193bfae06 X-V-A: X-V-T-CD: 9ad46be6e1c3c1a24e92ea4dad46d58d X-V-E-CD: 8dcd0bc8f52751ffdabdeee450fe4a7d X-V-R-CD: bafe279e2433716ca8c56ae0083e7365 X-V-CD: 0 X-V-ID: ff0ec444-24cb-466a-a41d-303882c67679 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-08-02_07:2021-08-02,2021-08-02 signatures=0 Received: from [17.235.10.84] (unknown [17.235.10.84]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QX800S6P4X7MR00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 02 Aug 2021 11:05:33 -0700 (PDT) MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] ArmVirt and Self-Updating Code From: "Andrew Fish" In-reply-to: <1042ebd1-30eb-420e-be10-2d5d7ec71373@localhost> Date: Mon, 02 Aug 2021 11:05:31 -0700 Cc: Ard Biesheuvel , Bret Barkelew , Thomas Abraham , "Ard Biesheuvel (TianoCore)" , "Lindholm, Leif" , Laszlo Ersek , Sami Mujawar , nd Message-id: References: <36b32106-da0e-bfd5-10cf-6c9bb86173d1@posteo.de> <39afb072-3e01-6946-9387-e414a8f62f8d@posteo.de> <1042ebd1-30eb-420e-be10-2d5d7ec71373@localhost> To: edk2-devel-groups-io , =?utf-8?Q?Marvin_H=C3=A4user?= X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-08-02_07:2021-08-02,2021-08-02 signatures=0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Aug 1, 2021, at 2:40 PM, Marvin H=C3=A4user wrot= e: >=20 > 01.08.2021 18:33:47 Ard Biesheuvel : >=20 >> On Sat, 31 Jul 2021 at 21:08, Marvin H=C3=A4user w= rote: >>> On 23.07.21 16:34, Ard Biesheuvel wrote: >>>> On Fri, 23 Jul 2021 at 16:27, Marvin H=C3=A4user = wrote: >>>>> On 23.07.21 16:09, Ard Biesheuvel wrote: >>>>>> On Fri, 23 Jul 2021 at 12:47, Marvin H=C3=A4user wrote: >>>>>>> =E2=80=A6 >>>> ... >>>>>>> =E2=80=A6 >>>>> Do you maybe have one final comment regarding that second question, >>>>> please? :) >>>> The RELA section is not converted into PE/COFF relocations. This woul= d >>>> not achieve a lot, given that no prior PE/COFF loader exists to >>>> process them. There is a snippet of asm code in the startup code that >>>> processes the R_AARCH64_RELATIVE relocation entries before calling >>>> into C code. >>> I searched for said ASM code till my fingers fell asleep and at last >>> found this: >>> https://github.com/tianocore/edk2/commit/b16fd231f6d8124fa05a0f0868409= 34b8709faf9#diff-3d563cc4775c7720900f4895bf619eed06291044aaa277fcc57eddc761= 8351a1L12-R148 >>> If I understand the commit message correctly, it is basically "pray th= e >>> C code does not use globals at all", which is fair enough, so maybe I >>> should document this in my proposed new library? I trust that this is >>> enough of a constraint for both ARM and AArch64, because I do not know >>> them at all. >> The C code can use globals, but not global pointer variables. But you >> are right, this is not very robust at all. >=20 > Right... Will document for my PE library. >=20 >>> What worries me is that StandaloneMmCore has no such ASM entry point a= t >>> all and instead it's just executing C directly. Also, it is not passed >>> the "-fno-jump-tables" flag that is commented to be important in the >>> commit linked above. >> This is because the StandaloneMmCore is built with -fpie, which >> already implies -fno-jump-tables, although I suppose this may not >> offer complete coverage for BASE libraries that are pulled into the >> link. >=20 > Ah okay, thanks. Out of curiosity of how ARM implements PIE, and how StM= mCore self-relocation can work *after* the PE/COFF section permissions have= been applied with .got merged into .text (i.e. read-only), I checked the G= CC5 "DLL" with readelf and found many relocations into the .text section. I= have no idea how any of this works, and no idea where to find out, but as = it apparently does, I might just update the PE calls and call it a day. I c= annot test anything either because there is no QEMU code for StMmCore I can= find. :( >=20 Marvin, It is useful to remember that there are object file (resolved by the linke= r), dynamic loading (resolved when the DLL is bound at runtime), and image = relocations. In the EFI PE/COFF we only end up with the image relocations t= hat need to be processed when an image is loaded into memory. I seem to rem= ember seeing the other classes of relocations still being present in the EL= F files, but they end up being a no-opt for EFI. You can look at the EFI PE= /COFF relocations to see the things EFI cares about.=20 Side note=E2=80=A6 The Xcode/clang toolchain requires the TEXT section to = not contain relocations for X64, and the linker will fail if there is code = that requires a relocation in the text section. This generally is not a pro= blem, but hand coded assembler can trigger a link failure that is specific = to Xcode.=20 Thanks, Andrew Fish > Thanks for your tireless replies! >=20 > Best regards, > Marvin >=20 >>> Best regards, >>> Marvin >>>> This also gives us the guarantee that no GOT indirections are >>>> dereferenced, given that our asm code simply does not do that. >>>>> Let's drop "GOT" and make it "any instruction that requires prior >>>>> relocation to function correctly". >>>> The thing to keep in mind here is that R_AARCH64_RELATIVE relocations >>>> never target instructions, but only memory locations that carry >>>> absolute addresses. This could be locations in .rodata or .data >>>> (global vars carrying pointer values), or GOT entries. >>>>>>> =E2=80=A6 >>>>>> Correct. And this works really well for shared libraries, where all >>>>>> text and data sections can be shared between processes, as they wil= l >>>>>> not be modified by the loader. All locations targeted by relocation= s >>>>>> will be nicely lumped together in the GOT. >>>>>> However, for bare metal style programs, there is no sharing, and th= ere >>>>>> is no advantage to lumping anything together. It is much better to = use >>>>>> relative references where possible, and simply apply relocations >>>>>> wherever needed across the text and data sections, >>>>>>> =E2=80=A6 >>>>>> The GOT is a special data structure used for implicit variable >>>>>> accesses, i.e., global vars used in the code. Statically initialize= d >>>>>> pointer variables are the other category, which are not code, and f= or >>>>>> which the same considerations do not apply, given that the right va= lue >>>>>> simply needs to be stored in the variable before the program starts= . >>>>>>> =E2=80=A6 >>>>>> The selection of 'code model' as it is called is controlled by GCC'= s >>>>>> -mcmodel=3D argument, which defaults to 'small' on AArch64, regardl= ess >>>>>> of whether you use PIC/PIE or not. >>>>> Aha, makes sense, thanks! >>>>> Best regards, >>>>> Marvin >>>>>>> =E2=80=A6 >=20 >=20 >=20 >=20 >=20 >=20