Page MenuHomePhabricator

Compiling bl31.elf with binutils 2.39 warns/fails with “ LOAD segment with RWX permissions”
Open, Needs TriagePublic

Description

To build atf-2.7 with binutils-2.39 - —no-warn-rwx-segment must be set when --fatal-warnings is used during builds.

relevant commit:

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107
The ELF linker will now generate a warning message if the stack is made
executable. Similarly it will warn if the output binary contains a
segment with all three of the read, write and execute permission
bits set. These warnings are intended to help developers identify
programs which might be vulnerable to attack via these executable
memory regions. The warnings are enabled by default but can be
disabled via a command line option.

compile error:
LD atf-2.7/build/sun50i_a64/release/bl31/bl31.elf
aarch64-none-elf-ld.bfd: warning: atf-2.7/build/sun50i_a64/release/bl31/bl31.elf has a LOAD segment with RWX permissions

Event Timeline

Hi Heitaum, Thanks for reporting this.

CJKay added a subscriber: CJKay.Sep 8 2022, 3:53 PM

Hi Heitbaum, could you tell me which toolchain you're using to build TF-A? The latest Arm GNU AArch64 toolchain is 11.3.Rel1, which packages binutils-2.38 and therefore compiles successfully, so I'm currently unable to reproduce this error.

Hey Chris, I may have raised the bug wrong we are tracking internally as its binutils-2.39, sorry!

@joannafarley-arm

Adding that the linking warns about both rwx-sections and execstack for bl2 too.
So both are needed or the linking needs to be fixed.
I think the no-warn flags are only available to newer tools, so defaulting to them will probably break things.

I can confirm this occurs with binutils 2.39. We (coreboot) are trying to update binutils from our toolchain and we are about to adjust our build system. --no-warn-rwx-segment fixes the issue. https://review.coreboot.org/c/coreboot/+/66920

Would be great if this could be fixed in your repository, since most likely many people will get this error sooner or later.

What's the status of this? Currently trying to build TF-A against the bookworm toolchain, and there the warning is even fatal. For now I'm working around it with this patch:

diff --git a/Makefile b/Makefile
index c4350dc16..07b4d5ccb 100644
--- a/Makefile
+++ b/Makefile
@@ -427,6 +427,7 @@ else ifneq ($(findstring gcc,$(notdir $(LD))),)
 # Pass ld options with Wl or Xlinker switches
 TF_LDFLAGS		+=	-Wl,--fatal-warnings -O1
 TF_LDFLAGS		+=	-Wl,--gc-sections
+TF_LDFLAGS		+=	-Wl,--no-warn-rwx-segment
 ifeq ($(ENABLE_LTO),1)
 	ifeq (${ARCH},aarch64)
 		TF_LDFLAGS	+=	-flto -fuse-linker-plugin
@@ -444,6 +445,7 @@ TF_LDFLAGS		+=	$(subst --,-Xlinker --,$(TF_LDFLAGS_$(ARCH)))
 else
 TF_LDFLAGS		+=	--fatal-warnings -O1
 TF_LDFLAGS		+=	--gc-sections
+TF_LDFLAGS		+=	--no-warn-rwx-segment
 # ld.lld doesn't recognize the errata flags,
 # therefore don't add those in that case
 ifeq ($(findstring ld.lld,$(notdir $(LD))),)

But before proposing this for upstream, I'd like to know if the issue can't be solved by actually not marking the executable section(s) writable.

CJKay added a comment.Sun, Jan 8, 10:52 AM

Hi Jan, sorry for the delay. This is currently in progress under the mixed-rwx topic: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18661/5

Thanks, good to know. So, 2.9 will likely carry a fix? Is there a better patch I can use already (the one referenced does not directly appear to solve the issue)?

CJKay added a comment.Sun, Jan 8, 11:29 AM

The patch stack is still a work in progress so BL1 is the only fixed image so far, but BL2 and BL31 need the same treatment. Your best bet until I get around to applying these fixes to the remaining images is the current workaround (TF_LDFLAGS="--no-warn-rwx-segment").