[edk2-devel] ArmVirt and Self-Updating Code
Marvin Häuser
mhaeuser at posteo.de
Sun Aug 1 21:40:12 UTC 2021
01.08.2021 18:33:47 Ard Biesheuvel <ardb at kernel.org>:
> On Sat, 31 Jul 2021 at 21:08, Marvin Häuser <mhaeuser at posteo.de> wrote:
>>
>> On 23.07.21 16:34, Ard Biesheuvel wrote:
>>> On Fri, 23 Jul 2021 at 16:27, Marvin Häuser <mhaeuser at posteo.de>
>>> wrote:
>>>>
>>>>
>>>> On 23.07.21 16:09, Ard Biesheuvel wrote:
>>>>> On Fri, 23 Jul 2021 at 12:47, Marvin Häuser <mhaeuser at posteo.de>
>>>>> wrote:
>>>>>> …
>>> ...
>>>>>> …
>>>> Do you maybe have one final comment regarding that second question,
>>>> please? :)
>>> The RELA section is not converted into PE/COFF relocations. This
>>> 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.
>>
>> I searched for said ASM code till my fingers fell asleep and at last
>> found this:
>> https://github.com/tianocore/edk2/commit/b16fd231f6d8124fa05a0f086840934b8709faf9#diff-3d563cc4775c7720900f4895bf619eed06291044aaa277fcc57eddc7618351a1L12-R148
>>
>> If I understand the commit message correctly, it is basically "pray
>> 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.
>>
>
> 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
>> 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.
>>
>
> 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
StMmCore 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 GCC5 "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 cannot test anything
either because there is no QEMU code for StMmCore I can find. :(
Thanks for your tireless replies!
Best regards,
Marvin
>
>
>> 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.
>>>
>>>>>> …
>>>>> Correct. And this works really well for shared libraries, where all
>>>>> text and data sections can be shared between processes, as they
>>>>> will
>>>>> not be modified by the loader. All locations targeted by
>>>>> relocations
>>>>> will be nicely lumped together in the GOT.
>>>>>
>>>>> However, for bare metal style programs, there is no sharing, and
>>>>> there
>>>>> 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,
>>>>>
>>>>>> …
>>>>> The GOT is a special data structure used for implicit variable
>>>>> accesses, i.e., global vars used in the code. Statically
>>>>> initialized
>>>>> pointer variables are the other category, which are not code, and
>>>>> for
>>>>> which the same considerations do not apply, given that the right
>>>>> value
>>>>> simply needs to be stored in the variable before the program
>>>>> starts.
>>>>>
>>>>>> …
>>>>> The selection of 'code model' as it is called is controlled by
>>>>> GCC's
>>>>> -mcmodel= argument, which defaults to 'small' on AArch64,
>>>>> regardless
>>>>> of whether you use PIC/PIE or not.
>>>> Aha, makes sense, thanks!
>>>>
>>>> Best regards,
>>>> Marvin
>>>>
>>>>>> …
>>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78474): https://edk2.groups.io/g/devel/message/78474
Mute This Topic: https://groups.io/mt/84380729/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list