I had faced a scenario like this:
There is a fuse.ko which is built as module of kernel source.
However, our team maintain the fuse as oot module.
There is a bug of (name it as B1) the original fuse.ko.
And our team fix B1 of fuse.ko as release it as oot module fuse_o1.ko.
Our system loaded fuse_o1.ko. Now, another team made a livepatch module base on
fuse.ko to fix B2 bug.
They load this livepatch_fuse.ko to the system, it fixed B2 bug, however, the
livepatch_fuse.ko revert the fix of fuse_o1.ko.
It expose the B1 bug which is already fix in fuse_o1.ko
The exposed B1 bug make fault to our cluster, which is a bad thing :(
This scenario shows the vulnerable of live-patching when handling
out-of-tree module.
I have a original solution to handle this:
• In kpatch-build, we would record the patched object, take the object of
ko as a list of parameters.
• Pass this ko list as parameter to create-klp-moudle.c
• For each patched ko object, we should read its srcversion from the
original module. If we use --oot-module, we would read the srcversion from the
oot moudle version.
• Store the target srcversion to a section named '.klp.target_srcversions'
• When the kpatch module loading, we shoud check if section
'.klp.target_srcversion' existed. If existed, we should check srcversion of the
patch target in the system match our recorded srcversion or not. If thet are
not match, refuse to load it. This can make sure the livepatch module would not
load the wrong target.
This function can avoid livepatch from patching the wrong version of the
function.
The original discussion can be seem on [1]. (Discussion with Joe Lawrence)
After the discussion, we think that the actual enforcement of this seems like a
job for kernel/livepatch/core.c.
Or it should be the process of sys call `init_module` when loading a module.
I am here waiting for Request For Comment. Before I do codes.
Thanks~~ ;)
Wardenjohn.
[1]: https://github.com/dynup/kpatch/issues/1435
