Aa64 fixes

[ozbenh]

These are three backports cherry-picked from a newer upstream (you can drop them if you rebase) and two fixes I added.

WARNING: The second fix might be controversial or might require further changes, see below:

• Add the missing .note.GNU-stack section to lib/ctors.S (that file is added by a RH specific patch)
• Fix section alignment issues, see below:

The issue with alignement is that the new binutils assume a 64k alignemnt for aarch64 by default. But the gnu-efi provided .lds doesn't align sections properly (.dynamic isn't aligned at all and it uses 4k for .data), so ld ends up putting everything in the same segment which ends up RWE which the new ld barfs about (and is a bad idea anyways).

Now, It can be overriden from the command line, so one solution would be to fix any user of gnu-efi (and the bundled magic Makefile fragments that Peter conveniently added but aren't upstream) to pass -z max-page-size=4096. That would have to be added to things like systemd-boot I suspect and possibly others.

The approach I chose instead (patch also sent to upstream gnu-efi mailing list without feedback so far) is to change the .lds to align everything to 64k on aa64.

HOWEVER: I just noticed that the .mk fragments that Fedora provides (not upstream) explicitely pass -DPAGE_SIZE=4096 -DPAGE_SHIFT=12 .. .that will probably need fixing, so that PR is incomplete, but I want to start the discussion (I'll send a fix for that later).

Is this the approach we want to take ? Or did I miss a bit of spec that says that EFI on aa64 only supports 4k pages ? using -z max-page-size is inconvenient as it can't be self contained in the .lds ...

[ozbenh]

Note.. the UEFI spec does say that for aarch64:

MMU configuration: Implementations must use only 4k pages and a single translation base
register. On devices supporting multiple translation base registers, TTBR0 must be used solely.
The binding does not mandate whether page tables are cached or un-cached.

So in theory, 4k is mandated as base page size for EFI binary and thus -DPAGE_SIZE is correct.

That means that in theory (again), -z maz-page-size=4096 is the correct approach, but it would require modifying the Makefile of every user of gnu-efi (including systemd-boot).

What do you reckon ? My patch still acts as a workaround...

[ozbenh]

So... we have two issues it seems :-) Passing -z maz-page-size=4096 isn't in itself sufficient. We also need to fix gnu-efi's .lds to properly put .dynamic in its own 4k block otherwise ld still does the wrong thing. I've verified that the page size argument alone doesn't fix it.

[ozbenh]

Allright, I've updated the PR. This time, I add 4 patches instead of the 2 mentioned earlier:

• Missing note section (same)
• Align .dynamic properly
• Pass -z max-page-size=4096 when building the apps
• Pass it as well in aa64.mk

[ozbenh]

There packages might need fixing for the ld argument:

[fedora@xxxxxxxx ~]$ repoquery --enablerepo fedora-source --whatrequires "gnu-efi*"
Last metadata expiration check: 0:03:19 ago on Wed 21 Dec 2022 04:12:28 AM UTC.
efitools-0:1.9.2-8.fc37.src
fwupd-efi-0:1.3-1.fc37.src
gnu-efi-devel-1:3.0.11-10.fc37.noarch
mokutil-2:0.6.0-5.fc37.src
pesign-test-app-0:5-27.fc37.src
sbsigntools-0:0.9.4-9.fc37.src
systemd-0:251.7-611.fc37.src

[ozbenh]

mokutil : seems to build fine without BuildRequires: gnu-efi .. however it does need BuildRequires: which for completeness (buildroot has it but it's never nice to depend implicitely is it ?)

[ozbenh]

LIttle fixup, let's not move .dynamic completely outside of the PE section definition, keep it in the data one.

BTW. Why do we keep those dynamic reloc sections around in the final PE ? I though they would be only useful if an ELF linker was interested in the object which ... won't happen. Or am I missing something subtle here ?