[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200225121125.psvuz6e7coa77vxe@pathway.suse.cz>
Date: Tue, 25 Feb 2020 13:11:25 +0100
From: Petr Mladek <pmladek@...e.com>
To: Miroslav Benes <mbenes@...e.cz>
Cc: Will Deacon <will@...nel.org>, linux-kernel@...r.kernel.org,
kernel-team@...roid.com, akpm@...ux-foundation.org,
"K . Prasad" <prasad@...ux.vnet.ibm.com>,
Thomas Gleixner <tglx@...utronix.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Frederic Weisbecker <frederic@...nel.org>,
Christoph Hellwig <hch@....de>,
Quentin Perret <qperret@...gle.com>,
Alexei Starovoitov <ast@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
live-patching@...r.kernel.org
Subject: Re: [PATCH 0/3] Unexport kallsyms_lookup_name() and
kallsyms_on_each_symbol()
On Tue 2020-02-25 11:05:39, Miroslav Benes wrote:
> CC live-patching ML, because this could affect many of its users...
>
> On Fri, 21 Feb 2020, Will Deacon wrote:
>
> > Hi folks,
> >
> > Despite having just a single modular in-tree user that I could spot,
> > kallsyms_lookup_name() is exported to modules and provides a mechanism
> > for out-of-tree modules to access and invoke arbitrary, non-exported
> > kernel symbols when kallsyms is enabled.
Just to explain how this affects livepatching users.
Livepatch is a module that inludes fixed copies of functions that
are buggy in the running kernel. These functions often
call functions or access variables that were defined static in
the original source code. There are two ways how this is currently
solved.
Some livepatch authors use kallsyms_lookup_name() to locate the
non-exported symbols in the running kernel and then use these
address in the fixed code.
Another possibility is to used special relocation sections,
see Documentation/livepatch/module-elf-format.rst
The problem with the special relocations sections is that the support
to generate them is not ready yet. The main piece would klp-convert
tool. Its development is pretty slow. The last version can be
found at
https://lkml.kernel.org/r/20190509143859.9050-1-joe.lawrence@redhat.com
I am not sure if this use case is enough to keep the symbols exported.
Anyway, there are currently some out-of-tree users.
Best Regards,
Petr
Powered by blists - more mailing lists