Live-Patching Archive on lore.kernel.org
 help / color / Atom feed
From: Miroslav Benes <mbenes@suse.cz>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Petr Mladek <pmladek@suse.com>,
	Joe Lawrence <joe.lawrence@redhat.com>,
	jikos@kernel.org, linux-kernel@vger.kernel.org,
	live-patching@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal
Date: Thu, 5 Sep 2019 14:03:34 +0200 (CEST)
Message-ID: <alpine.LSU.2.21.1909051355240.25712@pobox.suse.cz> (raw)
In-Reply-To: <20190905025055.36loaatxtkhdo4q5@treble>

On Wed, 4 Sep 2019, Josh Poimboeuf wrote:

> On Wed, Sep 04, 2019 at 10:49:32AM +0200, Petr Mladek wrote:
> > On Tue 2019-09-03 15:02:34, Miroslav Benes wrote:
> > > On Mon, 2 Sep 2019, Joe Lawrence wrote:
> > > 
> > > > On 9/2/19 12:13 PM, Miroslav Benes wrote:
> > > > >> I can easily foresee more problems like those in the future.  Going
> > > > >> forward we have to always keep track of which special sections are
> > > > >> needed for which architectures.  Those special sections can change over
> > > > >> time, or can simply be overlooked for a given architecture.  It's
> > > > >> fragile.
> > > > > 
> > > > > Indeed. It bothers me a lot. Even x86 "port" is not feature complete in
> > > > > this regard (jump labels, alternatives,...) and who knows what lurks in
> > > > > the corners of the other architectures we support.
> > > > > 
> > > > > So it is in itself reason enough to do something about late module
> > > > > patching.
> > > > > 
> > > > 
> > > > Hi Miroslav,
> > > > 
> > > > I was tinkering with the "blue-sky" ideas that I mentioned to Josh the other
> > > > day.
> > > 
> > > > I dunno if you had a chance to look at what removing that code looks
> > > > like, but I can continue to flesh out that idea if it looks interesting:
> > > 
> > > Unfortunately no and I don't think I'll come up with something useful 
> > > before LPC, so anything is really welcome.
> > > 
> > > > 
> > > >   https://github.com/joe-lawrence/linux/tree/blue-sky
> > > > 
> > > > A full demo would require packaging up replacement .ko's with a livepatch, as
> > > > well as "blacklisting" those deprecated .kos, etc.  But that's all I had time
> > > > to cook up last week before our holiday weekend here.
> > > 
> > > Frankly, I'm not sure about this approach. I'm kind of torn. The current 
> > > solution is far from ideal, but I'm not excited about the other options 
> > > either. It seems like the choice is basically between "general but 
> > > technically complicated fragile solution with nontrivial maintenance 
> > > burden", or "something safer and maybe cleaner, but limiting for 
> > > users/distros". Of course it depends on whether the limitation is even 
> > > real and how big it is. Unfortunately we cannot quantify it much and that 
> > > is probably why our opinions (in the email thread) differ.
> > 
> > I wonder what is necessary for a productive discussion on Plumbers:
> > 
> >   + Josh would like to see what code can get removed when late
> >     handling of modules gets removed. I think that it might be
> >     partially visible from Joe's blue-sky patches.
> 
> Yes, and I like what I see.  Especially the removal of the .klp.arch
> nastiness!
> 
> >   + I would like to better understand the scope of the current
> >     problems. It is about modifying code in the livepatch that
> >     depends on position of the related code:
> > 
> >       + relocations are rather clear; we will need them anyway
> > 	to access non-public (static) API from the original code.
> > 
> >       + What are the other changes?
> 
> I think the .klp.arch sections are the big ones:
> 
>   .klp.arch.altinstructions
>   .klp.arch.parainstructions
>   .klp.arch.jump_labels (doesn't exist yet)
> 
> And that's just x86...

I may misunderstand, but we have .klp.arch sections because para and 
alternatives have to be processed after relocations. And if we cannot get 
rid of relocations completely, because of static symbols, then we cannot 
get rid of .klp.arch sections either.
 
> And then of course there's the klp coming/going notifiers which have
> also been an additional source of complexity.

True, but I think we (me and Petr) do not consider it as much of a problem 
as you.

> I'd like to hear more specific negatives about Joe's recent patches,
> which IMO, are the best option we've discussed so far.

I'll reply elsewhere...

Miroslav

  parent reply index

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-19 12:28 [RFC PATCH 0/2] " Miroslav Benes
2019-07-19 12:28 ` [PATCH 1/2] livepatch: Nullify obj->mod in klp_module_coming()'s error path Miroslav Benes
2019-07-28 19:45   ` Josh Poimboeuf
2019-08-19 11:26     ` Petr Mladek
2019-07-19 12:28 ` [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal Miroslav Benes
2019-07-22  9:33   ` Petr Mladek
2019-08-14 12:33     ` Miroslav Benes
2019-07-28 20:04   ` Josh Poimboeuf
2019-08-14 11:06     ` Miroslav Benes
2019-08-14 15:12       ` Josh Poimboeuf
2019-08-16  9:46         ` Petr Mladek
2019-08-22 22:36           ` Josh Poimboeuf
2019-08-23  8:13             ` Petr Mladek
2019-08-26 14:54               ` Josh Poimboeuf
2019-08-27 15:05                 ` Joe Lawrence
2019-08-27 15:37                   ` Josh Poimboeuf
2019-09-02 16:13                 ` Miroslav Benes
2019-09-02 17:05                   ` Joe Lawrence
2019-09-03 13:02                     ` Miroslav Benes
2019-09-04  8:49                       ` Petr Mladek
2019-09-04 16:26                         ` Joe Lawrence
2019-09-05  2:50                         ` Josh Poimboeuf
2019-09-05 11:09                           ` Petr Mladek
2019-09-05 11:19                             ` Jiri Kosina
2019-09-05 13:23                               ` Josh Poimboeuf
2019-09-05 13:31                                 ` Jiri Kosina
2019-09-05 13:42                                   ` Josh Poimboeuf
2019-09-05 11:39                             ` Joe Lawrence
2019-09-05 13:08                             ` Josh Poimboeuf
2019-09-05 13:15                               ` Josh Poimboeuf
2019-09-05 13:52                                 ` Petr Mladek
2019-09-05 14:28                                   ` Josh Poimboeuf
2019-09-05 12:03                           ` Miroslav Benes [this message]
2019-09-05 12:35                             ` Josh Poimboeuf
2019-09-05 12:49                               ` Miroslav Benes
2019-09-05 11:52                         ` Miroslav Benes
2019-09-05  2:32                       ` Josh Poimboeuf
2019-09-05 12:16                         ` Miroslav Benes
2019-09-05 12:54                           ` Josh Poimboeuf
2019-09-06 12:51                             ` Miroslav Benes
2019-09-06 15:38                               ` Joe Lawrence
2019-09-06 16:45                               ` Josh Poimboeuf
2019-08-26 13:44         ` Nicolai Stange
2019-08-26 15:02           ` Josh Poimboeuf

Reply instructions:

You may reply publically 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.1909051355240.25712@pobox.suse.cz \
    --to=mbenes@suse.cz \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=pmladek@suse.com \
    /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

Live-Patching Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/live-patching/0 live-patching/git/0.git

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

Example config snippet for mirrors

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


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