On Mon, Aug 26, 2019 at 03:44:21PM +0200, Nicolai Stange wrote:
> Josh Poimboeuf <jpoimboe@xxxxxxxxxx> writes:
>
> > 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.
>
> Security concerns set aside, some of the patched modules might get
> distributed separately from the main kernel through some sort of
> kernel-*-extra packages and thus, not be found on some target system
> at all. Or they might have been blacklisted.
True.
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > - Changing 'atomic replace' to allow patch modules to be per-object.
> >
>
> Perhaps I'm misunderstanding, but supporting only per-object livepatch
> modules would make livepatch creation for something like commit
> 15fab63e1e57 ("fs: prevent page refcount overflow in pipe_buf_get"),
> CVE-2019-11487 really cumbersome (see the fuse part)?
Just don't change exported interfaces.
In this case you could leave generic_pipe_buf_get() alone and then
instead add a generic_pipe_buf_get__patched() which is called by the
patched fuse module. If you build the fuse-specific livepatch module
right, it would automatically have a dependency on the vmlinux-specific
livepatch module.
> I think I've seen similar interdependencies between e.g. kvm.ko <->
> kvm_intel.ko, but can't find an example right now.
--
Josh
