Live-Patching Archive on lore.kernel.org
 help / color / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Miroslav Benes <mbenes@suse.cz>,
	jikos@kernel.org, joe.lawrence@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: Thu, 22 Aug 2019 17:36:49 -0500
Message-ID: <20190822223649.ptg6e7qyvosrljqx@treble> (raw)
In-Reply-To: <20190816094608.3p2z73oxcoqavnm4@pathway.suse.cz>

On Fri, Aug 16, 2019 at 11:46:08AM +0200, Petr Mladek wrote:
> On Wed 2019-08-14 10:12:44, Josh Poimboeuf wrote:
> > On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes wrote:
> > > > Really, we should be going in the opposite direction, by creating module
> > > > dependencies, like all other kernel modules do, ensuring that a module
> > > > is loaded *before* we patch it.  That would also eliminate this bug.
> > > 
> > > Yes, but it is not ideal either with cumulative one-fixes-all patch 
> > > modules. It would load also modules which are not necessary for a 
> > > customer and I know that at least some customers care about this. They 
> > > want to deploy only things which are crucial for their systems.
> > 
> > If you frame the question as "do you want to destabilize the live
> > patching infrastucture" then the answer might be different.
> > 
> > We should look at whether it makes sense to destabilize live patching
> > for everybody, for a small minority of people who care about a small
> > minority of edge cases.
> 
> I do not see it that simple. Forcing livepatched modules to be
> loaded would mean loading "random" new modules when updating
> livepatches:

I don't want to start a long debate on this, because this idea isn't
even my first choice.  But we shouldn't dismiss it outright.

<devils-advocate>

>   + It means more actions and higher risk to destabilize
>     the system. Different modules have different quality.

Maybe the distro shouldn't ship modules which would destabilize the
system.

>   + It might open more security holes that are not fixed by
>     the livepatch.

Following the same line of thinking, the livepatch infrastructure might
open security holes because of the inherent complexity of late module
patching.

>   + It might require some extra configuration actions to handle
>     the newly opened interfaces (devices). For example, updating
>     SELinux policies.

I assume you mean user-created policies, not distro ones?  Is this even
a realistic concern?

>   + Are there conflicting modules that might need to get
>     livepatched?

Again is this realistic?

> This approach has a strong no-go from my side.

</devils-advocate>

I agree it's not ideal, but nothing is ideal at this point.  Let's not
to rule it out prematurely.  I do feel that our current approach is not
the best.  It will continue to create problems for us until we fix it.

>
> > Or maybe there's some other solution we haven't thought about, which
> > fits more in the framework of how kernel modules already work.
> >
> > > We could split patch modules as you proposed in the past, but that have 
> > > issues as well.
> 
> > Right, I'm not really crazy about that solution either.
> 
> Yes, this would just move the problem somewhere else.
> 
> 
> > Here's another idea: per-object patch modules.  Patches to vmlinux are
> > in a vmlinux patch module.  Patches to kvm.ko are in a kvm patch module.
> > That would require:
> > 
> > - Careful management of dependencies between object-specific patches.
> >   Maybe that just means that exported function ABIs shouldn't change.
> > 
> > - Some kind of hooking into modprobe to ensure the patch module gets
> >   loaded with the real one.
> 
> I see this just as a particular approach how to split livepatches
> per-object. The above points suggest how to handle dependencies
> on the kernel side.

Yes, they would need to be done on the distro / patch creation /
operational side.  They probably wouldn't affect livepatch code.

> > - Changing 'atomic replace' to allow patch modules to be per-object.
> 
> The problem might be how to transition all loaded objects atomically
> when the needed code is loaded from different modules.

I'm not sure what you mean.

My idea was that each patch module would be specific to an object, with
no inter-module change dependencies.  So when using atomic replace, if
the patch module is only targeted to vmlinux, then only vmlinux-targeted
patch modules would be replaced.

In other words, 'atomic replace' would be object-specific.

> Alternative would be to support only per-object consitency. But it
> might reduce the number of supported scenarios too much. Also it
> would make livepatching more error-prone.

Again, I don't follow.

-- 
Josh

  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 [this message]
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
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=20190822223649.ptg6e7qyvosrljqx@treble \
    --to=jpoimboe@redhat.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --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