linux-kernel - Re: [PATCH] ftrace: Do not reference symbols in sections without size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 16 Feb 2021 09:45:39 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] ftrace: Do not reference symbols in sections without size

On Tue, Feb 16, 2021 at 09:51:21AM -0500, Steven Rostedt wrote:
> On Tue, 16 Feb 2021 12:04:06 +0100
> Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> 
> > Thanks for this.
> > 
> > Should I also queue these up for 4.9 and 4.14 which do not have these
> > commits in them either (but somehow do not show the problem, yet)?
>
> This bothers me. I want to know exactly why this is a problem.

I actually see the same problem with 4.9 and 4.14, using the same
config.

It's very config-specific.  Something has to convince the toolchain to
not reference those two weak functions by section.

> That said, it is fine to backport those patches, and I would include 4.9
> and 4.14, as I would think you have a similar requirement that we have in
> the stable-rt trees. That is you shouldn't experience a regression going
> from an older kernel to a newer one because the older one had a fix
> backported to it that a newer one did not. Basically the same rationale that
> all fixes go into Linus's tree before backporting. We do the same on the
> stable-rt, where all fixes go in all maintained stable trees that are newer
> than the one you are backporting to.
> 
> Although, it does allow more to be traced than what recordmcount enables.
> But hopefully it doesn't cause any issues. Maybe I should do some ftrace
> testing before you go and release any of those stables with those patches.
> 
> I'm looking to see if this new "feature" of binutils isn't causing trouble
> elsewhere. I'm thinking that ftrace is just the canary here.

It already caused quite a bit of trouble with objtool (as did a previous
similar change by the Clang assembler).

-- 
Josh