+++ Jiri Kosina [13/07/15 21:16 +0200]:
On Mon, 13 Jul 2015, Jessica Yu wrote:
Do you think it would make sense for livepatch to instead establish a
module dependency requirement between the patch module and the
to-be-patched module(s), instead of relying on klp_module_notify()? i.e.
require the target module(s) be loaded before the patch module? Does it
make sense to apply a patch to a module that hasn't been loaded yet? In
what use cases would it make sense to patch module code without the
module itself being loaded?
I think this is not a good idea, at least if we are targetting distro
vendors as a primary consumers of livepatching infrastructure.
Consider the (not unlikely) scenario where a bugfix needs to alter core
network driver infrastructure (such as internal netdev API) and perform
corresponding fixups in many networking drivers at the same time.
As a distro vendor, you definitely want to ship this as a single
livepatch, but you absolutely don't want it to cause force modprobing of
every affected network driver on all systems that install that livepatch.
At the same time, you really do want to make sure that once the networking
driver gets eventually modprobed any time in the future (for example
network device is hotplugged), it gets patched upon load.
Hm, those are good points. I am currently trying to think of a
compromise, because I think abstracting away relocation work to the module
loader is a good move, or at the very least keeping architecture
specific code to the bare minimum. Otherwise attempting to port livepatch to
s390 will be very difficult and cumbersome, since there are some
relocation types that rely on symbol information (i.e. PLT and GOT
table indices) that the module loader has immediate access to, and that we
cannot access (at least easily) through livepatch.
The only problem left to solve then is patching unloaded modules with this
approach; one way of course is establishing module dependency (which
doesn't sound ideal, we don't want to load all those modules just to
patch them), another way is to consider removing support for patching
unloaded modules for the sake of simplification (but, it looks like
that might not be ideal either), and the third way that I'm
still thinking about is maybe hooking in some kind of work
queue to finish writing up relocations when the target modules get
loaded. This approach sounds just like what klp_module_notify should
be doing but the difference is that setting up work for the work queue
from *within* the module loader might give us access to the symbol information
we originally needed to write s390 relocs in the first place.
This idea is still premature and I'm not sure if it'll work, so I'm still
thinking...
--
To unsubscribe from this list: send the line "unsubscribe live-patching" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
