[edk2-devel] [RFC 13/13] ArmVirtPkg/ArmVirtQemu: Enable hardware enforced W^X memory permissions

[Ard Biesheuvel]

On Mon, 13 Feb 2023 at 23:23, Marvin Häuser <mhaeuser at posteo.de> wrote:
>
>
> On 13. Feb 2023, at 22:59, Ard Biesheuvel <ardb at kernel.org> wrote:
>
> No, the only reason for adding -fpie here is to ensure that statically
> initialized CONST pointers are emitted into .data.rel.ro and not into
> .rodata, as this is under the control of the compiler. Although,
> thinking about this, I wonder if we need to pass this to the linker
> for codegen under LTO as well. But the PIE link itself should be
> unnecessary here.
>
>
> Oh, what fun. For some reason I thought it would be unsafe to specify -fpie but not -pie, but considering PIE relocs are ignored either way, this actually makes perfect sense. Sorry! About that last part, the docs say: "It is recommended that you compile all the files participating in the same link with the same options and also specify those options at link time." [1], so good catch!
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
>

Yeah, but come to think of it, we pass the CC flags to the linker, so
this should be covered.

> But what about -fno-plt?
>

That doesn't make a difference in codegen on AArch64 - the same BL
instruction is emitted along with the same type of relocation, and it
is left up to the linker whether or not a PLT entry is emitted, and I
don't think it will ever do that when generating a fully linked binary
without -pie.

>
> It will if you pass -pie to the linker, which is why I would prefer to
> avoid that. The main issue IIRC is that the emit-relocs section does
> not cover the entries in the GOT table that also require relocation,
> and are only covered by the PIE .rela section. For AArch64, I added
> relaxation logic to GenFw to actually patch the instructions instead,
> which is always possible given the absence of dynamic linking.
> (d2687f23c909475d80cef32cdf9a5d121f0a9ae6,
> 7b8f69d7e10628d473dd225224d8c2122d25a38d)
>
>
> Yes, seen, very nice. I do wonder though why GOT entries are generated in the first place when symbols are all local and data is within the PC-addressable range. Just today, for a X64 build, I actually saw Clang relax a GOT reference to __stack_chk_guard itself.
>

Yeah there are some strange corner cases, but in general, all symbol
references are relative - it is precisely the 'special' symbol
references that the compiler generates internally that sometimes get
this wrong.

>
> This means that we don't have to care about compiler generated symbol
> references, and so the relocs emitted by emit-relocs are sufficient,
> and the additional ones emitted into .rela are unused anyway. The only
> remaining absolute references are the ones resulting from statically
> initialized globals, and those will either be in .data or in
> .data.rel.ro (if -fpie is being used)
>
>
> Right. thank you.
>
> Best regards,
> Marvin
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100142): https://edk2.groups.io/g/devel/message/100142
Mute This Topic: https://groups.io/mt/96937498/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-