linux-kernel - Re: arm64 ftrace fixes for v5.4.y

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAE-0n510j3=h16Xp98dsBj8MkkP+cfpaEz+_WBuPTxyWxyWZvQ@mail.gmail.com>
Date:   Fri, 18 Feb 2022 13:51:46 -0800
From:   Stephen Boyd <swboyd@...omium.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     stable@...r.kernel.org, linux-kernel@...r.kernel.org,
        Steven Rostedt <rostedt@...dmis.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        Mark Rutland <mark.rutland@....com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Sami Tolvanen <samitolvanen@...gle.com>
Subject: Re: arm64 ftrace fixes for v5.4.y

Quoting Greg KH (2022-02-18 01:01:35)
> On Thu, Feb 17, 2022 at 05:27:33PM -0800, Stephen Boyd wrote:
> > Hi stable maintainers,
> >
> > I recently ran into an issue where trying to load a module with jump
> > table entries crashes the system when function tracing is enabled. The
> > crash happens because ftrace is modifying the code and then marking it
> > as read-only too early. ftrace_make_call() calls module_enable_ro(mod,
> > true) before module init is over because ftrace_module_enable() calls
> > __ftrace_replace_code() which does FTRACE_UPDATE_MAKE_CALL. All this
> > code is gone now upstream but is still present on v5.4 stable kernels. I
> > picked this set of patches to v5.4 and it fixed it for me.
> >
> > fbf6c73c5b26 ftrace: add ftrace_init_nop()
> > a1326b17ac03 module/ftrace: handle patchable-function-entry
> > bd8b21d3dd66 arm64: module: rework special section handling
> > f1a54ae9af0d arm64: module/ftrace: intialize PLT at load time
>
> These all apply just fine, thanks.

Cool, thanks!

>
> > after doing that I ran into another issue because I'm using clang. Would
> > it be possible to pick two more patches to the stable tree to silence
> > this module warning from sysfs complaining about
> > /module/<modname>/sections/__patchable_function_entries being
> > duplicated?
> >
> > dd2776222abb kbuild: lto: merge module sections
> > 6a3193cdd5e5 kbuild: lto: Merge module sections if and only if
> > CONFIG_LTO_CLANG is enabled
>
> These two do not apply to the 5.4.y branch, as the file they touch is
> not present in 5.4.y.  They do apply to 5.10.y, so I've queued them up
> there, but I think you need to provide a working backport please.

Ok. Good news! They're not necessary. I looked further and found that I
had originally picked the entire arm64 series, including commit
3b23e4991fb6 ("arm64: implement ftrace with regs"). Then I ran into the
problem where __patchable_function_entries wasn't being combined by the
linker script. I picked those extra lto patches and it fixed it. Then I
peeled away the new ftrace with regs feature because they were big and
scary and not necessary. Now I've narrowed it down to only needing the
one line from the first lto patch:

  __patchable_function_entries : { *(__patchable_function_entries) }

in combination with the ftrace with regs support.

Long story short, they aren't needed unless commit 3b23e4991fb6 ("arm64:
implement ftrace with regs") is picked, which isn't needed because we
don't need that feature, just the part where we initialize PLT at load
time and stop patching the code up too early, mistakenly enabling RO
protection before the module is done being formed.