[kvm-unit-tests PATCH 0/2] Rework LDFLAGS and link with noexecstack

[kvm-unit-tests PATCH 0/2] Rework LDFLAGS and link with noexecstack

[Thomas Huth]

I noticed that the latest version of ld (in Fedora rawhide) emits
a warning on x86 and s390x, complaining about missing .note.GNU-stack
section that implies an executable stack. It can be silenced by
linking with "-z noexecstack".

While trying to add this switch globally to the kvm-unit-tests, I
had to discover that the common LDFLAGS are hardly used anywhere,
so the first patch cleans up that problem first before adding the
new flag in the second patch.

Thomas Huth (2):
  Rework the common LDFLAGS to become more useful again
  Link with "-z noexecstack" to avoid warning from newer versions of ld

 Makefile                | 2 +-
 arm/Makefile.common     | 2 +-
 powerpc/Makefile.common | 2 +-
 s390x/Makefile          | 2 +-
 x86/Makefile.common     | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.39.3

[kvm-unit-tests PATCH 1/2] Rework the common LDFLAGS to become more useful again

[Thomas Huth]

Currently the LDFLAGS settings from the main Makefile are ignored in
most architecture specific directories (except s390x), which is very
confusing when you try to add a linker switch for all architectures.

Let's change this so that all architectures extend the common LDFLAGS
instead of replacing them. So it is sufficient now to specify the
"-nostdlib" switch in the main Makefile now instead of repeating it
everywhere.

While we're at it, avoid to repeat the whole set of CFLAGS in the
common LDFLAGS - the options that are meant for the C compiler should
not be exposed unconditionally to the linker.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 Makefile                | 2 +-
 arm/Makefile.common     | 2 +-
 powerpc/Makefile.common | 2 +-
 s390x/Makefile          | 2 +-
 x86/Makefile.common     | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Makefile b/Makefile
index 6ed5deac..0e5d85a1 100644
--- a/Makefile
+++ b/Makefile
@@ -96,7 +96,7 @@ CFLAGS += -Woverride-init -Wmissing-prototypes -Wstrict-prototypes
 
 autodepend-flags = -MMD -MF $(dir $*).$(notdir $*).d
 
-LDFLAGS += $(CFLAGS)
+LDFLAGS += -nostdlib
 
 $(libcflat): $(cflatobjs)
 	$(AR) rcs $@ $^
diff --git a/arm/Makefile.common b/arm/Makefile.common
index 1bbec64f..e2cb1a56 100644
--- a/arm/Makefile.common
+++ b/arm/Makefile.common
@@ -60,7 +60,7 @@ libeabi = lib/arm/libeabi.a
 eabiobjs = lib/arm/eabi_compat.o
 
 FLATLIBS = $(libcflat) $(LIBFDT_archive) $(libeabi)
-%.elf: LDFLAGS = -nostdlib $(arch_LDFLAGS)
+%.elf: LDFLAGS += $(arch_LDFLAGS)
 %.elf: %.o $(FLATLIBS) $(SRCDIR)/arm/flat.lds $(cstart.o)
 	$(CC) $(CFLAGS) -c -o $(@:.elf=.aux.o) $(SRCDIR)/lib/auxinfo.c \
 		-DPROGNAME=\"$(@:.elf=.flat)\" -DAUXFLAGS=$(AUXFLAGS)
diff --git a/powerpc/Makefile.common b/powerpc/Makefile.common
index 8ce00340..f8f47490 100644
--- a/powerpc/Makefile.common
+++ b/powerpc/Makefile.common
@@ -49,7 +49,7 @@ OBJDIRS += lib/powerpc
 
 FLATLIBS = $(libcflat) $(LIBFDT_archive)
 %.elf: CFLAGS += $(arch_CFLAGS)
-%.elf: LDFLAGS = $(arch_LDFLAGS) -nostdlib -pie -n
+%.elf: LDFLAGS += $(arch_LDFLAGS) -pie -n
 %.elf: %.o $(FLATLIBS) $(SRCDIR)/powerpc/flat.lds $(cstart.o) $(reloc.o)
 	$(CC) $(CFLAGS) -c -o $(@:.elf=.aux.o) $(SRCDIR)/lib/auxinfo.c \
 		-DPROGNAME=\"$@\"
diff --git a/s390x/Makefile b/s390x/Makefile
index a80db538..d75e86c2 100644
--- a/s390x/Makefile
+++ b/s390x/Makefile
@@ -76,7 +76,7 @@ CFLAGS += -O2
 CFLAGS += -march=zEC12
 CFLAGS += -mbackchain
 CFLAGS += -fno-delete-null-pointer-checks
-LDFLAGS += -nostdlib -Wl,--build-id=none
+LDFLAGS += -Wl,--build-id=none
 
 # We want to keep intermediate files
 .PRECIOUS: %.o %.lds
diff --git a/x86/Makefile.common b/x86/Makefile.common
index 365e199f..e64aac52 100644
--- a/x86/Makefile.common
+++ b/x86/Makefile.common
@@ -31,7 +31,7 @@ endif
 
 OBJDIRS += lib/x86
 
-$(libcflat): LDFLAGS += -nostdlib $(arch_LDFLAGS)
+$(libcflat): LDFLAGS += $(arch_LDFLAGS)
 $(libcflat): CFLAGS += -ffreestanding -I $(SRCDIR)/lib -I lib
 
 COMMON_CFLAGS += -m$(bits)
@@ -62,7 +62,7 @@ else
 # We want to keep intermediate file: %.elf and %.o
 .PRECIOUS: %.elf %.o
 
-%.elf: LDFLAGS = -nostdlib $(arch_LDFLAGS)
+%.elf: LDFLAGS += $(arch_LDFLAGS)
 %.elf: %.o $(FLATLIBS) $(SRCDIR)/x86/flat.lds $(cstart.o)
 	$(LD) $(LDFLAGS) -T $(SRCDIR)/x86/flat.lds -o $@ \
 		$(filter %.o, $^) $(FLATLIBS)
-- 
2.39.3

[kvm-unit-tests PATCH 2/2] Link with "-z noexecstack" to avoid warning from newer versions of ld

[Thomas Huth]

Newer versions of ld (from binutils 2.40) complain on s390x and x86:

 ld: warning: s390x/cpu.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

We can silence these warnings by using "-z noexecstack" for linking
(which should not have any real influence on the kvm-unit-tests since
the information from the ELF header is not used here anyway, so it's
just cosmetics).

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 0e5d85a1..20f7137c 100644
--- a/Makefile
+++ b/Makefile
@@ -96,7 +96,7 @@ CFLAGS += -Woverride-init -Wmissing-prototypes -Wstrict-prototypes
 
 autodepend-flags = -MMD -MF $(dir $*).$(notdir $*).d
 
-LDFLAGS += -nostdlib
+LDFLAGS += -nostdlib -z noexecstack
 
 $(libcflat): $(cflatobjs)
 	$(AR) rcs $@ $^
-- 
2.39.3

Re: [kvm-unit-tests PATCH 2/2] Link with "-z noexecstack" to avoid warning from newer versions of ld

[Sean Christopherson]

On Fri, Jun 23, 2023, Thomas Huth wrote:
> Newer versions of ld (from binutils 2.40) complain on s390x and x86:
> 
>  ld: warning: s390x/cpu.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
> 
> We can silence these warnings by using "-z noexecstack" for linking
> (which should not have any real influence on the kvm-unit-tests since
> the information from the ELF header is not used here anyway, so it's
> just cosmetics).
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 0e5d85a1..20f7137c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -96,7 +96,7 @@ CFLAGS += -Woverride-init -Wmissing-prototypes -Wstrict-prototypes
>  
>  autodepend-flags = -MMD -MF $(dir $*).$(notdir $*).d
>  
> -LDFLAGS += -nostdlib
> +LDFLAGS += -nostdlib -z noexecstack

Drat, the pull request[1] I sent to Paolo yesterday only fixes x86[2].

Paolo, want me to redo the pull request to drop the x86-specific patch? 

[1] https://lore.kernel.org/all/20230622211440.2595272-1-seanjc@google.com
[2] https://lore.kernel.org/all/20230406220839.835163-1-seanjc@google.com

Re: [kvm-unit-tests PATCH 0/2] Rework LDFLAGS and link with noexecstack

[Andrew Jones]

On Fri, Jun 23, 2023 at 02:54:14PM +0200, Thomas Huth wrote:
> I noticed that the latest version of ld (in Fedora rawhide) emits
> a warning on x86 and s390x, complaining about missing .note.GNU-stack
> section that implies an executable stack. It can be silenced by
> linking with "-z noexecstack".
> 
> While trying to add this switch globally to the kvm-unit-tests, I
> had to discover that the common LDFLAGS are hardly used anywhere,
> so the first patch cleans up that problem first before adding the
> new flag in the second patch.
> 
> Thomas Huth (2):
>   Rework the common LDFLAGS to become more useful again
>   Link with "-z noexecstack" to avoid warning from newer versions of ld
> 
>  Makefile                | 2 +-
>  arm/Makefile.common     | 2 +-
>  powerpc/Makefile.common | 2 +-
>  s390x/Makefile          | 2 +-
>  x86/Makefile.common     | 4 ++--
>  5 files changed, 6 insertions(+), 6 deletions(-)
> 
> -- 
> 2.39.3
>

For the series

Reviewed-by: Andrew Jones <andrew.jones@linux.dev>

Re: [kvm-unit-tests PATCH 2/2] Link with "-z noexecstack" to avoid warning from newer versions of ld

[Thomas Huth]

On 23/06/2023 16.24, Sean Christopherson wrote:
> On Fri, Jun 23, 2023, Thomas Huth wrote:
>> Newer versions of ld (from binutils 2.40) complain on s390x and x86:
>>
>>   ld: warning: s390x/cpu.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
>>
>> We can silence these warnings by using "-z noexecstack" for linking
>> (which should not have any real influence on the kvm-unit-tests since
>> the information from the ELF header is not used here anyway, so it's
>> just cosmetics).
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>>   Makefile | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 0e5d85a1..20f7137c 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -96,7 +96,7 @@ CFLAGS += -Woverride-init -Wmissing-prototypes -Wstrict-prototypes
>>   
>>   autodepend-flags = -MMD -MF $(dir $*).$(notdir $*).d
>>   
>> -LDFLAGS += -nostdlib
>> +LDFLAGS += -nostdlib -z noexecstack
> 
> Drat, the pull request[1] I sent to Paolo yesterday only fixes x86[2].

Oops, sorry, I did not notice that patch in my overcrowded mailboxes (or 
forgot about it during KVM forum...) :-/

> Paolo, want me to redo the pull request to drop the x86-specific patch?

I can also respin my patch on top of your series later ... the problem 
currently also only seems to happen on x86 and s390x, on ppc64 and aarch64, 
the linker does not complain ... so maybe it's even better to do it 
per-architecture only anyway? Opinions?

  Thomas

Re: [kvm-unit-tests PATCH 2/2] Link with "-z noexecstack" to avoid warning from newer versions of ld

[Sean Christopherson]

On Fri, Jun 23, 2023, Thomas Huth wrote:
> On 23/06/2023 16.24, Sean Christopherson wrote:
> > On Fri, Jun 23, 2023, Thomas Huth wrote:
> > > Newer versions of ld (from binutils 2.40) complain on s390x and x86:
> > > 
> > >   ld: warning: s390x/cpu.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
> > > 
> > > We can silence these warnings by using "-z noexecstack" for linking
> > > (which should not have any real influence on the kvm-unit-tests since
> > > the information from the ELF header is not used here anyway, so it's
> > > just cosmetics).
> > > 
> > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > ---
> > >   Makefile | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/Makefile b/Makefile
> > > index 0e5d85a1..20f7137c 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -96,7 +96,7 @@ CFLAGS += -Woverride-init -Wmissing-prototypes -Wstrict-prototypes
> > >   autodepend-flags = -MMD -MF $(dir $*).$(notdir $*).d
> > > -LDFLAGS += -nostdlib
> > > +LDFLAGS += -nostdlib -z noexecstack
> > 
> > Drat, the pull request[1] I sent to Paolo yesterday only fixes x86[2].
> 
> Oops, sorry, I did not notice that patch in my overcrowded mailboxes (or
> forgot about it during KVM forum...) :-/

Heh, you gave a Reviewed-by[*], so either its the latter, or you've got a clone
running around :-)

[*] https://lore.kernel.org/all/916aac4f-97b8-70c2-de39-87438eb4aea4@redhat.com

> > Paolo, want me to redo the pull request to drop the x86-specific patch?
> 
> I can also respin my patch on top of your series later ... the problem
> currently also only seems to happen on x86 and s390x, on ppc64 and aarch64,
> the linker does not complain ... so maybe it's even better to do it
> per-architecture only anyway? Opinions?

I don't think it makes sense to do this per-arch, other architectures likely aren't
problematic purely because of linker specific behavior, e.g. see

https://patches.linaro.org/project/binutils/patch/1506025575-1559-1-git-send-email-jim.wilson@linaro.org

Re: [kvm-unit-tests PATCH 2/2] Link with "-z noexecstack" to avoid warning from newer versions of ld

[Thomas Huth]

On 27/06/2023 00.34, Sean Christopherson wrote:
> On Fri, Jun 23, 2023, Thomas Huth wrote:
>> On 23/06/2023 16.24, Sean Christopherson wrote:
>>> On Fri, Jun 23, 2023, Thomas Huth wrote:
>>>> Newer versions of ld (from binutils 2.40) complain on s390x and x86:
>>>>
>>>>    ld: warning: s390x/cpu.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
>>>>
>>>> We can silence these warnings by using "-z noexecstack" for linking
>>>> (which should not have any real influence on the kvm-unit-tests since
>>>> the information from the ELF header is not used here anyway, so it's
>>>> just cosmetics).
>>>>
>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>> ---
>>>>    Makefile | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/Makefile b/Makefile
>>>> index 0e5d85a1..20f7137c 100644
>>>> --- a/Makefile
>>>> +++ b/Makefile
>>>> @@ -96,7 +96,7 @@ CFLAGS += -Woverride-init -Wmissing-prototypes -Wstrict-prototypes
>>>>    autodepend-flags = -MMD -MF $(dir $*).$(notdir $*).d
>>>> -LDFLAGS += -nostdlib
>>>> +LDFLAGS += -nostdlib -z noexecstack
>>>
>>> Drat, the pull request[1] I sent to Paolo yesterday only fixes x86[2].
...
>>> Paolo, want me to redo the pull request to drop the x86-specific patch?
>>
>> I can also respin my patch on top of your series later ... the problem
>> currently also only seems to happen on x86 and s390x, on ppc64 and aarch64,
>> the linker does not complain ... so maybe it's even better to do it
>> per-architecture only anyway? Opinions?
> 
> I don't think it makes sense to do this per-arch, other architectures likely aren't
> problematic purely because of linker specific behavior, e.g. see
> 
> https://patches.linaro.org/project/binutils/patch/1506025575-1559-1-git-send-email-jim.wilson@linaro.org

Ok, I've pushed now my patches since other people were running into this 
issue, too (see 
https://lore.kernel.org/kvm/20230809091717.1549-1-nrb@linux.ibm.com/ ).

Sean, could you please rebase your series now?

  Thanks,
   Thomas