LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Miroslav Benes <mbenes@suse.cz>
To: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Petr Mladek <pmladek@suse.com>, Will Deacon <will@kernel.org>,
	linux-kernel@vger.kernel.org, kernel-team@android.com,
	akpm@linux-foundation.org,
	"K . Prasad" <prasad@linux.vnet.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	Quentin Perret <qperret@google.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	live-patching@vger.kernel.org
Subject: Re: [PATCH 0/3] Unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()
Date: Tue, 25 Feb 2020 19:01:25 +0100 (CET)
Message-ID: <alpine.LSU.2.21.2002251854550.1630@pobox.suse.cz> (raw)
In-Reply-To: <943e7093-2862-53c6-b7f4-96c7d65789b9@redhat.com>


[-- Attachment #1: Type: text/plain, Size: 3764 bytes --]

On Tue, 25 Feb 2020, Joe Lawrence wrote:

> On 2/25/20 7:11 AM, Petr Mladek wrote:
> > 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.
> > 
> 
> FWIW, kallsyms was historically used by the out-of-tree kpatch support module
> to resolve external symbols as well as call set_memory_r{w,o}() API.  All of
> that support code has been merged upstream, so modern kpatch modules* no
> longer leverage kallsyms by default.

Good. Quick grep through the sources gave me a couple of hits, so I was 
not sure.
 
> * That said, there are still some users who still use the deprecated support
> module with newer kernels, but that is not officially supported by the
> project.
> 
> > 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.
> > 
> 
> Another (temporary?) klp-relocation issue is that binutils has limited support
> for them as currently implemented:
> 
>   https://sourceware.org/ml/binutils/2020-02/msg00317.html
> 
> For example, try running strip or objcopy on a .ko that includes them and you
> may find surprising results :(
> 
> 
> As far as the klp-convert patchset goes, I forget whether or not we tied its
> use case to source-based livepatch creation.  If kallsyms goes unexported,
> perhaps it finds more immediate users.
>
> However since klp-convert provides nearly the same functionality as kallsyms,
> i.e. both can be used to circumvent symbol export licensing -- one could make
> similar arguments against its inclusion.

In a way yes, but as Masami described elsewhere in the thread there are 
more convenient ways to circumvent it even now. Not as convenient as 
kallsyms, of course. 
 
> If there is renewed (or greater, to be more accurate) interest in the
> klp-convert patchset, we can dust it off and see what's left.  AFAIK it was
> blocked on arch-specific klp-relocations and whether per-object​ livepatch
> modules would remove that requirement.

Yes, I think it is on standby now. I thought about it while walking 
through Petr's module split patch set and it seemed to me that klp-convert 
could be made much much simpler on top of that. So we should start there.

Anyway, as far as Will's patch set is concerned, there is no real obstacle 
on our side, is there?

Alexei mentioned ksplice from git history, but no one cares about ksplice 
in upstream now, I would say.

Thanks
Miroslav

  reply index

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-21 11:44 Will Deacon
2020-02-21 11:44 ` [PATCH 1/3] samples/hw_breakpoint: Drop HW_BREAKPOINT_R when reporting writes Will Deacon
2020-02-21 14:12   ` Christoph Hellwig
2020-02-21 11:44 ` [PATCH 2/3] samples/hw_breakpoint: Drop use of kallsyms_lookup_name() Will Deacon
2020-02-21 14:13   ` Christoph Hellwig
2020-02-21 14:20     ` Will Deacon
2020-02-21 11:44 ` [PATCH 3/3] kallsyms: Unexport kallsyms_lookup_name() and kallsyms_on_each_symbol() Will Deacon
2020-02-21 11:53   ` Greg Kroah-Hartman
2020-02-21 14:14   ` Christoph Hellwig
2020-02-21 15:11   ` Alexei Starovoitov
2020-02-21 14:27 ` [PATCH 0/3] " Masami Hiramatsu
2020-02-21 14:48   ` Will Deacon
2020-02-21 23:44     ` Masami Hiramatsu
2020-02-21 15:41 ` David Laight
2020-02-21 16:25   ` Quentin Perret
2020-02-25 10:05 ` Miroslav Benes
2020-02-25 12:11   ` Petr Mladek
2020-02-25 15:00     ` Joe Lawrence
2020-02-25 18:01       ` Miroslav Benes [this message]
2020-02-26 14:16         ` Joe Lawrence
2020-03-02 19:28 ` Mathieu Desnoyers
2020-03-02 19:36   ` Greg Kroah-Hartman
2020-03-02 19:39     ` Greg Kroah-Hartman
2020-03-02 20:17       ` Mathieu Desnoyers
2020-03-03  6:57         ` Greg Kroah-Hartman
2020-03-03 16:58           ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.21.2002251854550.1630@pobox.suse.cz \
    --to=mbenes@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=frederic@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=joe.lawrence@redhat.com \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=pmladek@suse.com \
    --cc=prasad@linux.vnet.ibm.com \
    --cc=qperret@google.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git