On Mon, Aug 26, 2019 at 03:44:21PM +0200, Nicolai Stange wrote:

Josh Poimboeuf [off-list ref] writes:

quoted

On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes wrote:

quoted

quoted

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.

quoted

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.

quoted

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