Re: [PATCH 5.15 5.10 5.4 1/1] arm64: fix Build ID if CONFIG_MODVERSIONS

Re: [PATCH 5.15 5.10 5.4 1/1] arm64: fix Build ID if CONFIG_MODVERSIONS

[Tom Saeger]

On Thu, Dec 08, 2022 at 09:34:40PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Dec 06, 2022 at 01:43:08PM -0700, Tom Saeger wrote:
> > Backport of: 0d362be5b142 ("Makefile: link with -z noexecstack --no-warn-rwx-segments")
> > breaks arm64 Build ID when CONFIG_MODVERSIONS=y.
> > 
> > CONFIG_MODVERSIONS adds extra tooling to calculate symbol versions.
> > This kernel's KBUILD tooling uses both
> > relocatable (-r) and (-z noexecstack) to link head.o
> > which results in ld adding a .note.GNU-stack section.
> > Final linking of vmlinux should add a .NOTES segment containing the
> > Build ID, but does NOT if head.o has a .note.GNU-stack section.
> > 
> > Selectively remove -z noexecstack from head.o's KBUILD_LDFLAGS to
> > prevent .note.GNU-stack from being added to head.o.  Final link of
> > vmlinux then properly adds .NOTES segment containing Build ID that can
> > be read using tools like 'readelf -n'.
> > 
> > Cc: <stable@vger.kernel.org> # 5.15, 5.10, 5.4
> > Signed-off-by: Tom Saeger <tom.saeger@oracle.com>
> > ---
> >  arch/arm64/kernel/Makefile | 5 +++++
> >  1 file changed, 5 insertions(+)
> 
> Why isn't this needed in Linus's tree?

0d362be5b142 ("Makefile: link with -z noexecstack --no-warn-rwx-segments")

was merged after
7b4537199a4a ("kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS")

Linus's tree never had -z noexecstack with these same KBUILD rules.

> 
> And why not cc: everyone involved in this, I would need acks from
> maintainers to be able to accept this...

Fair request.

Between ~5.3 and 5.19-rc1 cherry-picking 
0d362be5b142 ("Makefile: link with -z noexecstack --no-warn-rwx-segments")
and building arm64 with CONFIG_MODVERSIONS=y
results in vmlinux missing Build ID

head.S is compiled to head.o
head.o is linked (ld) with -r and -z noexecstack  which adds .note.GNU-stack section in head.o
head.o is then linked again with vmlinux (resulting vmlinux is missing .NOTE segment)


Can folks confirm/deny ld behavior is expected (arm64)?
And whether the above patch would be an acceptable fix for these kernel
versions?

repro test in cover letter: https://lore.kernel.org/all/cover.1670358255.git.tom.saeger@oracle.com/#r

Regards,
--Tom


> 
> thanks,
> 
> greg k-h

Re: [PATCH 5.15 5.10 5.4 1/1] arm64: fix Build ID if CONFIG_MODVERSIONS

[Greg Kroah-Hartman]

On Thu, Dec 08, 2022 at 05:31:06PM -0600, Tom Saeger wrote:
> On Thu, Dec 08, 2022 at 09:34:40PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Dec 06, 2022 at 01:43:08PM -0700, Tom Saeger wrote:
> > > Backport of: 0d362be5b142 ("Makefile: link with -z noexecstack --no-warn-rwx-segments")
> > > breaks arm64 Build ID when CONFIG_MODVERSIONS=y.
> > > 
> > > CONFIG_MODVERSIONS adds extra tooling to calculate symbol versions.
> > > This kernel's KBUILD tooling uses both
> > > relocatable (-r) and (-z noexecstack) to link head.o
> > > which results in ld adding a .note.GNU-stack section.
> > > Final linking of vmlinux should add a .NOTES segment containing the
> > > Build ID, but does NOT if head.o has a .note.GNU-stack section.
> > > 
> > > Selectively remove -z noexecstack from head.o's KBUILD_LDFLAGS to
> > > prevent .note.GNU-stack from being added to head.o.  Final link of
> > > vmlinux then properly adds .NOTES segment containing Build ID that can
> > > be read using tools like 'readelf -n'.
> > > 
> > > Cc: <stable@vger.kernel.org> # 5.15, 5.10, 5.4
> > > Signed-off-by: Tom Saeger <tom.saeger@oracle.com>
> > > ---
> > >  arch/arm64/kernel/Makefile | 5 +++++
> > >  1 file changed, 5 insertions(+)
> > 
> > Why isn't this needed in Linus's tree?
> 
> 0d362be5b142 ("Makefile: link with -z noexecstack --no-warn-rwx-segments")
> 
> was merged after
> 7b4537199a4a ("kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS")
> 
> Linus's tree never had -z noexecstack with these same KBUILD rules.

Then it needs to say that, in detail, in this changelog please.

> > And why not cc: everyone involved in this, I would need acks from
> > maintainers to be able to accept this...
> 
> Fair request.
> 
> Between ~5.3 and 5.19-rc1 cherry-picking 
> 0d362be5b142 ("Makefile: link with -z noexecstack --no-warn-rwx-segments")
> and building arm64 with CONFIG_MODVERSIONS=y
> results in vmlinux missing Build ID
> 
> head.S is compiled to head.o
> head.o is linked (ld) with -r and -z noexecstack  which adds .note.GNU-stack section in head.o
> head.o is then linked again with vmlinux (resulting vmlinux is missing .NOTE segment)
> 
> 
> Can folks confirm/deny ld behavior is expected (arm64)?
> And whether the above patch would be an acceptable fix for these kernel
> versions?
> 
> repro test in cover letter: https://lore.kernel.org/all/cover.1670358255.git.tom.saeger@oracle.com/#r

Please resend, no need for a cover letter for just one patch, and
include all of the needed info in the changelog itself.

thanks,

greg k-h

Re: [PATCH 5.15 5.10 5.4 1/1] arm64: fix Build ID if CONFIG_MODVERSIONS

[Nick Desaulniers]

On Thu, Dec 8, 2022 at 3:31 PM Tom Saeger <tom.saeger@oracle.com> wrote:
>
> Can folks confirm/deny ld behavior is expected (arm64)?
> And whether the above patch would be an acceptable fix for these kernel
> versions?

If you remove `-z noexecstack`, aren't you just going to trigger
warnings from BFD again?

At the least consider adding a fixes tag for 0d362be5b142, and note
that stable doesn't have
7b4537199a4a, in the commit message.
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH 5.15 5.10 5.4 1/1] arm64: fix Build ID if CONFIG_MODVERSIONS

[Tom Saeger]

On Fri, Dec 09, 2022 at 09:58:42AM -0800, Nick Desaulniers wrote:
> On Thu, Dec 8, 2022 at 3:31 PM Tom Saeger <tom.saeger@oracle.com> wrote:
> >
> > Can folks confirm/deny ld behavior is expected (arm64)?
> > And whether the above patch would be an acceptable fix for these kernel
> > versions?
> 
> If you remove `-z noexecstack`, aren't you just going to trigger
> warnings from BFD again?

hmm, probably so, let me check

> 
> At the least consider adding a fixes tag for 0d362be5b142, and note
> that stable doesn't have
> 7b4537199a4a, in the commit message.
> -- 
> Thanks,
> ~Nick Desaulniers