Hi Steve,

Thanks for the ping on this.

Adhemerval, Oliver, are either of you familiar with this stuff https://sourceware.org/bugzilla/show_bug.cgi?id=26206 ?

Regards,

-- Maxim Kuvyrkov https://www.linaro.org

On 25 Jun 2021, at 15:13, Steve McIntyre 93sam@debian.org wrote:

Hi folks,

I'm hoping that I might be able to get some development help with binutils for aarch64...

I'm maintaining the UEFI Secure Boot stack in Debian (shim etc.), including for arm64/aarch64 (as I wanted to make that work too!). UEFI binaries are awkward for those of used to the Linux and ELF world - they're PE/COFF format with different calling conventions to match the Microsoft world. But we've made things work.

On x86 platforms, the shim build process uses objcopy --target=efi-app-$(ARCH) to produce the final output binaries. We've never had similar support for the aarch64 platform, and instead somebody came up with a method using locally-hacked linker script and "-O binary" to generate the output binaries. That's worked well enough for a while, but it's been annoying for various reasons (particularly debugging problems).

*However*, recently for security reasons we've tweaked the layout of Secure Boot binaries [1] and this has caused lots of problems. The older hacks to hand-build the right sections etc. needed significant extra work, and we're still dealing with awkward bugs related to this. Based ont these problems, I recently had to make the painful decision to drop support for arm64 SB in Debian. I know that other distributions are feeling similar pain. :-(

Rather than continuing to hack on things, I think it's (way past) time that we did things correctly! We need aarch64 binary format support in binutils so we can just use it like we do on x86. AFAICS, there is already a bug open asking for this from last year [2]. Could I please prevail on some friendly neighourhood aarch64 toolchain engineer to help with that?

Thanks for considering,

Steve

[1] https://github.com/rhboot/shim/blob/main/SBAT.md [2] https://sourceware.org/bugzilla/show_bug.cgi?id=26206#add_comment

-- Steve McIntyre, Cambridge, UK. steve@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead

---

linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Hi Adhemerval,

On Mon, Jun 28, 2021 at 04:37:34PM -0300, Adhemerval Zanella wrote:

Peter Jones from Red Hat (pjones@redhat.com ) seems to working on adding support for aarch64, by the last common on the thread. His work seems to be quite recent (6th may), so we might want to check with him if he is planning to finish this work.

AIUI Peter started hacking on this a while back, but he told me he was definitely looking for somebody to restart or pick it up. It's not really his area of expertise. I've added him in CC here...

Another option might to check lld, we have it working on llvm for windows on aarch64. It might be ready available or require less adjustment than add the full binutils support.

Ideally it would be nice to have more than just objcopy/ld. At the moment debugging builds is awkward; objdump refuses to do anything useful with our binaries, for example.

On Tue, Jun 29, 2021 at 03:32:15PM +0100, Steve McIntyre wrote:

Hi Adhemerval,

On Mon, Jun 28, 2021 at 04:37:34PM -0300, Adhemerval Zanella wrote:

...

Peter Jones from Red Hat (pjones@redhat.com ) seems to working on adding support for aarch64, by the last common on the thread. His work seems to be quite recent (6th may), so we might want to check with him if he is planning to finish this work.

AIUI Peter started hacking on this a while back, but he told me he was definitely looking for somebody to restart or pick it up. It's not really his area of expertise. I've added him in CC here...

Most of the work in that tree was done in 2019; in May I did a rebase to the current upstream tree and separated out the one relocation type (absolute, type 0) that we desperately need to work, and moved all the types where I'm wildly unsure of the implementation, and which we don't need with the *current* consumers, to their own patch on a different branch[0]. GitHub has made the conscious choice to show the wrong date on commits, and that's probably giving the impression I'm more actively working on this.

I'm happy to help in terms of what we need as consumers and why, and to any extent I'm able design and organization, but I don't have a lot of time to spend on this code and am not an expert on how it *should* be structured. In particular, the (internal to BFD) PE .h generation I've currently got, which tells our C files how our target is configured and thus is shared among various PE targets, is absolutely *craaaap*.

...

Another option might to check lld, we have it working on llvm for windows on aarch64. It might be ready available or require less adjustment than add the full binutils support.

It works for some things but not others. lld-link (the windows/PE targeting linker[1]) doesn't support several of the linker options we need which the ELF-targeting one does, in particular there's no concept like linker scripts and adding arbitrary sections was remarkably difficult when last I looked, as are simple things like _text/_etext symbols to mark the start and end of sections in a way you can reference directly from C code. That makes it hard to implement .vendor_cert and .sbat, notably including the SBAT self-check. The .vendor_cert problem is obnoxious, but the SBAT problems are a show-stopper. It also doesn't currently support EFI the EFI-specific machine types; edk2 post-processes the resulting binary to get EFI targets, which is exactly the sort of hacking we'd like to see less of[2].

We'd need to put work in there to make it useful as well.

Ideally it would be nice to have more than just objcopy/ld. At the moment debugging builds is awkward; objdump refuses to do anything useful with our binaries, for example.

Very true, and also at some point we definitely need to figure out something better than 'gcc -nostartfiles' to make a .so, and providing our startup files and C runtime as .a/.o files. Making it use target-specific startup files and crt0, so we can actually build real EFI binaries without having to link in a separate runtime tree, would be really nice. Right now, AFAIK gcc doesn't know about EFI targets at all, but *my* thinking has been that isn't even worth addressing with binutils in the state it's in. I bet I'm not the only one.

[0] https://github.com/vathpela/binutils/commit/45118328e907c6e81c61d4130df72d59... [1] It amazes me that clang got the "target is distinct from the linker binary you execute" thing completely right (unlike gcc) but lld got it completely wrong (mostly unlike binutils), but here we are. [2] That said, at this point I could do it trivially in the shim tree; we have a linter that can do this sort of thing.