From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by mx.groups.io with SMTP id smtpd.web11.12266.1627854016585075618 for ; Sun, 01 Aug 2021 14:40:17 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=DYxh0Jme; spf=pass (domain: posteo.de, ip: 185.67.36.66, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id DD7DE240109 for ; Sun, 1 Aug 2021 23:40:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1627854013; bh=JGKzjOhUXMRmykN6CmwsQt/vuYFJ2X5qgrLGuBTsvmA=; h=Date:From:To:Cc:Subject:From; b=DYxh0JmelMlgRn0CwO38rKF/2MHfN7xUZymUpthyNjxlMOPIw0Zq+gnFbd7o3UEO1 CsmBfNMH3AGhI5I5ZRfmUW2TR4oMdz97+VYPD2qeGhfhFHz9dojQEv2sJhU1nH0z5A Y+pLozP1fmCO/31cg4gavSirUY8mXVF6+06c740uIdkskbHwiiaF46Ces9Xbp+hx+F VgPZzevlvz2yvoQJVRh7W32V5sR37S2gkddM6cPPeR9wTlAJnl2OJ1vKO6LFvGRI6B zII8ezYx72//mJBXpI2jyWzWwGVardfZncjjmP0VBV61Pjj0lxVamblyvIxuidfBH/ QbC/oRGK4MYbQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4GdF0r4cG8z9rxK; Sun, 1 Aug 2021 23:40:12 +0200 (CEST) MIME-Version: 1.0 Date: Sun, 01 Aug 2021 21:40:12 +0000 From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= To: devel@edk2.groups.io, ardb@kernel.org Cc: Bret Barkelew , Thomas Abraham , "Ard Biesheuvel (TianoCore)" , "Lindholm, Leif" , Laszlo Ersek , Sami Mujawar , nd Subject: Re: [edk2-devel] ArmVirt and Self-Updating Code In-Reply-To: References: <36b32106-da0e-bfd5-10cf-6c9bb86173d1@posteo.de> <39afb072-3e01-6946-9387-e414a8f62f8d@posteo.de> Message-ID: <1042ebd1-30eb-420e-be10-2d5d7ec71373@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 01.08.2021 18:33:47 Ard Biesheuvel : > On Sat, 31 Jul 2021 at 21:08, Marvin H=C3=A4user wr= ote: >>=20 >> On 23.07.21 16:34, Ard Biesheuvel wrote: >>> On Fri, 23 Jul 2021 at 16:27, Marvin H=C3=A4user = =20 >>> wrote: >>>>=20 >>>>=20 >>>> On 23.07.21 16:09, Ard Biesheuvel wrote: >>>>> On Fri, 23 Jul 2021 at 12:47, Marvin H=C3=A4user =20 >>>>> 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=20 >>> would >>> 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. >>=20 >> I searched for said ASM code till my fingers fell asleep and at last >> found this: >> https://github.com/tianocore/edk2/commit/b16fd231f6d8124fa05a0f08684093= 4b8709faf9#diff-3d563cc4775c7720900f4895bf619eed06291044aaa277fcc57eddc7618= 351a1L12-R148 >>=20 >> If I understand the commit message correctly, it is basically "pray=20 >> the >> 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. >>=20 >=20 > The C code can use globals, but not global pointer variables. But you > are right, this is not very robust at all. Right... Will document for my PE library. >> What worries me is that StandaloneMmCore has no such ASM entry point=20 >> at >> 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. >>=20 >=20 > 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. Ah okay, thanks. Out of curiosity of how ARM implements PIE, and how=20 StMmCore self-relocation can work *after* the PE/COFF section=20 permissions have been applied with .got merged into .text (i.e.=20 read-only), I checked the GCC5 "DLL" with readelf and found many=20 relocations into the .text section. I have no idea how any of this=20 works, and no idea where to find out, but as it apparently does, I might= =20 just update the PE calls and call it a day. I cannot test anything=20 either because there is no QEMU code for StMmCore I can find. :( Thanks for your tireless replies! Best regards, Marvin >=20 >=20 >> Best regards, >> Marvin >>=20 >>> This also gives us the guarantee that no GOT indirections are >>> dereferenced, given that our asm code simply does not do that. >>>=20 >>>> Let's drop "GOT" and make it "any instruction that requires prior >>>> relocation to function correctly". >>>>=20 >>> 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. >>>=20 >>>>>> =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=20 >>>>> will >>>>> not be modified by the loader. All locations targeted by=20 >>>>> relocations >>>>> will be nicely lumped together in the GOT. >>>>>=20 >>>>> However, for bare metal style programs, there is no sharing, and=20 >>>>> there >>>>> is no advantage to lumping anything together. It is much better to= =20 >>>>> use >>>>> relative references where possible, and simply apply relocations >>>>> wherever needed across the text and data sections, >>>>>=20 >>>>>> =E2=80=A6 >>>>> The GOT is a special data structure used for implicit variable >>>>> accesses, i.e., global vars used in the code. Statically=20 >>>>> initialized >>>>> pointer variables are the other category, which are not code, and=20 >>>>> for >>>>> which the same considerations do not apply, given that the right=20 >>>>> value >>>>> simply needs to be stored in the variable before the program=20 >>>>> starts. >>>>>=20 >>>>>> =E2=80=A6 >>>>> The selection of 'code model' as it is called is controlled by=20 >>>>> GCC's >>>>> -mcmodel=3D argument, which defaults to 'small' on AArch64,=20 >>>>> regardless >>>>> of whether you use PIC/PIE or not. >>>> Aha, makes sense, thanks! >>>>=20 >>>> Best regards, >>>> Marvin >>>>=20 >>>>>> =E2=80=A6 >>=20 >=20 >=20 >=20