Bug 27753 - -mx86-used-note= defaulting to yes regresses
Summary: -mx86-used-note= defaulting to yes regresses
Status: RESOLVED WONTFIX
Alias: None
Product: binutils
Classification: Unclassified
Component: gas (show other bugs)
Version: 2.36.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-19 15:26 UTC by Jan Beulich
Modified: 2021-06-21 19:41 UTC (History)
2 users (show)

See Also:
Host:
Target: x86
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beulich 2021-04-19 15:26:29 UTC
In the Xen project, to test the internal insn emulator, we have a simple way of generating binary blobs to hand to the emulator:

%.bin: %.c
	$(CC) $(filter-out -M% .%,$(CFLAGS)) -c $<
	$(LD) $(LDFLAGS_DIRECT) -N -Ttext 0x100000 -o $*.tmp $*.o
	$(OBJCOPY) -O binary $*.tmp $@

Up to 2.35 this has been working fine. The introduction (by default) of the .note.gnu.property section has led to all of the resulting *.bin files to be about 128Mb in size.

Such options causing extra content to be created should imo never default to true.
Comment 1 H.J. Lu 2021-04-19 20:19:06 UTC
It sounds like .note.gnu.property section is unused.  Please pass
-R .note.gnu.property to objcopy to remove it.
Comment 2 Jan Beulich 2021-04-20 08:31:26 UTC
(In reply to H.J. Lu from comment #1)
> It sounds like .note.gnu.property section is unused.  Please pass
> -R .note.gnu.property to objcopy to remove it.

That's what I'm meaning to do as a workaround, but as per

https://lists.xen.org/archives/html/xen-devel/2021-04/msg01002.html

there are reservations against this approach. No workaround should have been necessary here in the first place.

Perhaps the issue wouldn't have occurred if the section hadn't SHF_ALLOC set. Is there a specific reason for this? The gABI looks to mandate the flag to be clear for SHT_NOTE type sections.
Comment 3 H.J. Lu 2021-04-20 11:57:51 UTC
(In reply to Jan Beulich from comment #2)
> (In reply to H.J. Lu from comment #1)
> > It sounds like .note.gnu.property section is unused.  Please pass
> > -R .note.gnu.property to objcopy to remove it.
> 
> That's what I'm meaning to do as a workaround, but as per
> 
> https://lists.xen.org/archives/html/xen-devel/2021-04/msg01002.html
> 
> there are reservations against this approach. No workaround should have been
> necessary here in the first place.
> 
> Perhaps the issue wouldn't have occurred if the section hadn't SHF_ALLOC
> set. Is there a specific reason for this? The gABI looks to mandate the flag
> to be clear for SHT_NOTE type sections.

All note sections in Linux binary have SHF_ALLOC:

  [ 2] .note.gnu.build-id NOTE            004001d0 0001d0 000024 00   A  0   0  4
  [ 3] .note.gnu.property NOTE            004001f4 0001f4 000034 00   A  0   0  4
  [ 4] .note.ABI-tag     NOTE            00400228 000228 000020 00   A  0   0  4
Comment 4 Fangrui Song 2021-06-17 19:06:03 UTC
This is the status quo. The trend is more and more enabled-by-default security hardening features. They need markers in object files and linked images.

Many firmware/freestanding style builds don't like such features. They have to opt opt, e.g. -fno-pic -fno-stack-protector -fstack-check-no -fcf-protection=none -no-pie

xen was relying on a non-guaranteed layout.
Comment 5 Jan Beulich 2021-06-18 10:44:41 UTC
(In reply to Fangrui Song from comment #4)
> xen was relying on a non-guaranteed layout.

And how would you suggest we prevent such happening again, in case yet more stuff gets added to images by default? We can't really predict (read: guess) e.g. suitable -R options to pass to objcopy.

As I also can't spot any justification in any of the earlier comments that this is "not a bug", I'm further putting the entry here back to "unconfirmed". Comment 3 saying "All note sections in Linux binary have SHF_ALLOC" is an observation, but not an answer to my question, which was referring to the gABI. If the gABI is violated, then the note sections in Linux ought to be fixed imo. Which in turn would prevent .note.* related issues like this one to occur again going forward.
Comment 6 Fangrui Song 2021-06-18 16:16:51 UTC
A dynamic loader needs PT_GNU_PROPERTY to know the ISA usage of a component.
.note.gnu.property makes up PT_GNU_PROPERTY. Therefore, the section needs to SHF_ALLOC to be part of the program image.

% cat a.c
int main() {}
% gcc -o a a.c -nostdlib -Wl,-N -static -Wl,-Ttext=0x10000 -fuse-ld=bfd
/usr/bin/ld.bfd: warning: cannot find entry symbol _start; defaulting to 0000000000010000

If you use objcopy -O binary, you will notice that the output as 4mib. Why? Because the linker generates .note.gnu.build-id . You need -Wl,--build-id=none to remove it.

  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        0000000000010000 000190 00000b 00 WAX  0   0  1
  [ 2] .note.gnu.property NOTE            0000000000400190 0001d8 000030 00   A  0   0  8
  [ 3] .note.gnu.build-id NOTE            00000000004001c0 000208 000024 00   A  0   0  4
  [ 4] .eh_frame         PROGBITS        0000000000010010 0001a0 000038 00   A  0   0  8
  [ 5] .comment          PROGBITS        0000000000000000 00022c 00002e 01  MS  0   0  1
  [ 6] .symtab           SYMTAB          0000000000000000 000260 000120 18      7   7  8
  [ 7] .strtab           STRTAB          0000000000000000 000380 000022 00      0   0  1
  [ 8] .shstrtab         STRTAB          0000000000000000 0003a2 00005a 00      0   0  1

You may use -Wa,-mx86-used-note=no to remove .note.gnu.property

GNU ld -z separate-code has a separate issue, the segment layout isn't particular good: https://sourceware.org/bugzilla/show_bug.cgi?id=24490 
two R around RX are wasteful. Ideally there is only one R and it precedes RX.
Comment 7 Jan Beulich 2021-06-21 06:40:51 UTC
(In reply to Fangrui Song from comment #6)
> A dynamic loader needs PT_GNU_PROPERTY to know the ISA usage of a component.
> .note.gnu.property makes up PT_GNU_PROPERTY. Therefore, the section needs to
> SHF_ALLOC to be part of the program image.

You fail to address my pointing out of this not being compliant to gABI. I also don't buy the argument that the dynamic loader needs the note sections mapped into memory. It can very well simply read them from the file. (I can see that it's _easier_ if they get mapped, but that's not an excuse to violate gABI, which I assume has good reasons to state what it states.)

> If you use objcopy -O binary, you will notice that the output as 4mib. Why?
> Because the linker generates .note.gnu.build-id . You need
> -Wl,--build-id=none to remove it.
> [...]
> You may use -Wa,-mx86-used-note=no to remove .note.gnu.property

This doesn't address my question as to making oneself immune to future such binutils changes.
Comment 8 H.J. Lu 2021-06-21 12:51:21 UTC
If you don't need NOTE sections, just discard them in the linker script.
Comment 9 Jan Beulich 2021-06-21 15:08:26 UTC
(In reply to H.J. Lu from comment #8)
> If you don't need NOTE sections, just discard them in the linker script.

As per above there's no linker script involved here, and for the simple purposes here there imo shouldn't be such a requirement imposed by changes to binutils. IOW I don't view this as an answer to my request.
Comment 10 H.J. Lu 2021-06-21 19:41:51 UTC
(In reply to Jan Beulich from comment #9)
> (In reply to H.J. Lu from comment #8)
> > If you don't need NOTE sections, just discard them in the linker script.
> 
> As per above there's no linker script involved here, and for the simple
> purposes here there imo shouldn't be such a requirement imposed by changes
> to binutils. IOW I don't view this as an answer to my request.

Please try this linker script:

SECTIONS { /DISCARD/ : { *(.note.*) } }
INSERT AFTER .text;

This should discard all note sections.