On Mon, Jul 13, 2015 at 08:51:29PM -0400, Jessica Yu wrote: > +++ 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... I think all the symbol table and relocation metadata is thrown out after the module is initialized. So that might be a pretty big blocker for the third approach. -- Josh -- 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
