| Message ID | 20230329123814.76051-1-thuth@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [kvm-unit-tests] x86/flat.lds: Silence warnings about empty loadable segments | expand |
On Wed, 29 Mar 2023 14:38:14 +0200, Thomas Huth wrote: > Recent versions of objcopy (e.g. from Fedora 37) complain: > > objcopy: x86/vmx.elf: warning: empty loadable segment detected at > vaddr=0x400000, is this intentional? > > Seems like we can silence these warnings by properly specifying > program headers in the linker script. > > [...] Applied to kvm-x86 next, thanks! On the topic of annoying warnings, this one is also quite annoying: ld: warning: setjmp64.o: missing .note.GNU-stack section implies executable stack ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker I thought "-z noexecstack" would make it go away, but either I'm wrong or I'm not getting the flag set in the right place. [1/1] x86/flat.lds: Silence warnings about empty loadable segments https://github.com/kvm-x86/kvm-unit-tests/commit/0a06949aafac -- https://github.com/kvm-x86/kvm-unit-tests/tree/next
On 06/04/2023 01.01, Sean Christopherson wrote: > On Wed, 29 Mar 2023 14:38:14 +0200, Thomas Huth wrote: >> Recent versions of objcopy (e.g. from Fedora 37) complain: >> >> objcopy: x86/vmx.elf: warning: empty loadable segment detected at >> vaddr=0x400000, is this intentional? >> >> Seems like we can silence these warnings by properly specifying >> program headers in the linker script. >> >> [...] > > Applied to kvm-x86 next, thanks! Thanks for picking it up! > On the topic of annoying warnings, this one is also quite annoying: > > ld: warning: setjmp64.o: missing .note.GNU-stack section implies executable stack > ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker > > I thought "-z noexecstack" would make it go away, but either I'm wrong or I'm not > getting the flag set in the right place. I never saw that warning here before, but I'm currently also still using an older version of GCC and binutils here since my development machine is still using RHEL 8 ... Anyway, does this happen for the normal builds, or for the efi builds? I can see a .note.GNU-stack entry in x86/efi/elf_x86_64_efi.lds ... maybe we need something similar in x86/flat.lds ? Thomas
On Thu, Apr 06, 2023, Thomas Huth wrote: > On 06/04/2023 01.01, Sean Christopherson wrote: > > On Wed, 29 Mar 2023 14:38:14 +0200, Thomas Huth wrote: > > > Recent versions of objcopy (e.g. from Fedora 37) complain: > > > > > > objcopy: x86/vmx.elf: warning: empty loadable segment detected at > > > vaddr=0x400000, is this intentional? > > > > > > Seems like we can silence these warnings by properly specifying > > > program headers in the linker script. > > > > > > [...] > > > > Applied to kvm-x86 next, thanks! > > Thanks for picking it up! > > > On the topic of annoying warnings, this one is also quite annoying: > > > > ld: warning: setjmp64.o: missing .note.GNU-stack section implies executable stack > > ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker > > > > I thought "-z noexecstack" would make it go away, but either I'm wrong or I'm not > > getting the flag set in the right place. > > I never saw that warning here before, but I'm currently also still using an > older version of GCC and binutils here since my development machine is still > using RHEL 8 ... > > Anyway, does this happen for the normal builds, or for the efi builds? Normal builds with gcc 12. I figured out what I got wrong, the "-z noexecstack" needs to be passed to the linker, not the compiler/assembler. This does the trick, I'll post an official patch later today: diff --git a/x86/Makefile.common b/x86/Makefile.common index 365e199f..c57d418a 100644 --- a/x86/Makefile.common +++ b/x86/Makefile.common @@ -62,7 +62,7 @@ else # We want to keep intermediate file: %.elf and %.o .PRECIOUS: %.elf %.o -%.elf: LDFLAGS = -nostdlib $(arch_LDFLAGS) +%.elf: LDFLAGS = -nostdlib $(arch_LDFLAGS) -z noexecstack %.elf: %.o $(FLATLIBS) $(SRCDIR)/x86/flat.lds $(cstart.o) $(LD) $(LDFLAGS) -T $(SRCDIR)/x86/flat.lds -o $@ \ $(filter %.o, $^) $(FLATLIBS) > I can see a .note.GNU-stack entry in x86/efi/elf_x86_64_efi.lds ... maybe we > need something similar in x86/flat.lds ? I believe that just telling the linker that those sections don't need relocation info. I suspect it's unnecessary copy+paste from UEFI sources. The linker warning from setjmp64.o (and cstart64.o) is yelling about _not_ having .note.GNU-stack, which is a magic section that tells the linker that the binary doesn't need an executable stack. If I'm reading the NOTE correctly, it's saying that the ability to have an executable stack is soon going away.
On 4/6/23 19:16, Sean Christopherson wrote: >> I can see a .note.GNU-stack entry in x86/efi/elf_x86_64_efi.lds ... maybe we >> need something similar in x86/flat.lds ? > I believe that just telling the linker that those sections don't need relocation > info. I suspect it's unnecessary copy+paste from UEFI sources. > > The linker warning from setjmp64.o (and cstart64.o) is yelling about_not_ having > .note.GNU-stack, which is a magic section that tells the linker that the binary > doesn't need an executable stack. If I'm reading the NOTE correctly, it's saying > that the ability to have an executable stack is soon going away. More or less; if I remember correctly they want to flip the default from executable stack to non-executable stack. If you want an executable stack you'll have to add an ELF note or link with -z execstack. All of this of course is irrelevant in a freestanding environment. Paolo
diff --git a/x86/flat.lds b/x86/flat.lds index 337bc44f..017a8500 100644 --- a/x86/flat.lds +++ b/x86/flat.lds @@ -1,18 +1,24 @@ +PHDRS +{ + text PT_LOAD FLAGS(5); + data PT_LOAD FLAGS(6); +} + SECTIONS { . = 4M + SIZEOF_HEADERS; stext = .; - .text : { *(.init) *(.text) *(.text.*) } + .text : { *(.init) *(.text) *(.text.*) } :text etext = .; . = ALIGN(4K); .data : { *(.data) exception_table_start = .; *(.data.ex) - exception_table_end = .; - } + exception_table_end = .; + } :data . = ALIGN(16); - .rodata : { *(.rodata) } + .rodata : { *(.rodata) } :data . = ALIGN(16); .bss : { *(.bss) } . = ALIGN(4K);
Recent versions of objcopy (e.g. from Fedora 37) complain: objcopy: x86/vmx.elf: warning: empty loadable segment detected at vaddr=0x400000, is this intentional? Seems like we can silence these warnings by properly specifying program headers in the linker script. Signed-off-by: Thomas Huth <thuth@redhat.com> --- x86/flat.lds | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)