From: Petr Mladek <pmladek@suse.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: Joe Lawrence <joe.lawrence@redhat.com>,
jikos@kernel.org, Josh Poimboeuf <jpoimboe@redhat.com>,
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: Wed, 4 Sep 2019 10:49:32 +0200 [thread overview]
Message-ID: <20190904084932.gndrtewubqiaxmzy@pathway.suse.cz> (raw)
In-Reply-To: <alpine.LSU.2.21.1909031447140.3872@pobox.suse.cz>
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.
+ 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?
+ Do we use them in livepatches? How often?
+ How often new problematic features appear?
+ Would be possible to detect potential problems, for example
by comparing the code in the binary and in memory when
the module is loaded the normal way?
+ Would be possible to reset the livepatch code in memory
when the related module is unloaded and safe us half
of the troubles?
+ It might be useful to prepare overview of the existing proposals
and agree on the positives and negatives. I am afraid that some
of them might depend on the customer base and
use cases. Sometimes we might not have enough information.
But it might be good to get on the same page where possible.
Anyway, it might rule out some variants so that we could better
concentrate on the acceptable ones. Or come with yet another
proposal that would avoid the real blockers.
Any other ideas?
Would it be better to discuss this in a separate room with
a whiteboard or paperboard?
Best Regards,
Petr
next prev parent reply other threads:[~2019-09-04 8:49 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 12:28 [RFC PATCH 0/2] livepatch: Clear relocation targets on a module removal 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 [this message]
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
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 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=20190904084932.gndrtewubqiaxmzy@pathway.suse.cz \
--to=pmladek@suse.com \
--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=mbenes@suse.cz \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).