Hi all, We've been working on a way to remove kpatch's dependence on dynrela sections to write relocations and to offload the brunt of this work to the kernel module loader (i.e. load_module()). Doing so will remove the need for architecture-specific code (i.e. klp_write_module_reloc()), since the module loader itself will take care of symbol resolution and relocations. This will simplify the logic in kpatch's create-diff-object code as well as completely eliminate the need for livepatch code to deal with relocations. The motivation for this change is to be able to eventually support livepatch on s390x, where we've encountered numerous roadblocks in dealing with certain s390 PLT+GOT relocation types that cannot be easily handled in klp_write_module_reloc() due to a dependence on symbol information livepatch cannot provide, but that the module loader has access to. This change will eliminate the need for klp_write_module_reloc(), and the main plus is that livepatch will be more architecture-independent. The remaining problem is, however, dealing with modules that are not loaded upon patch module load. Currently we patch modules that aren't loaded yet by using klp_module_notify() to finish the patching process once the target module has been loaded. However, once we remove dynrelas and relocation code in livepatch, writing relocations will become impossible at that point, because load_module() (for the patch module) will have already finished executing, and that is where we were supposed to have written all our relocations and performed all symbol resolutions already. This change can therefore only patch modules that have already been loaded, and is incompatible with the current klp_module_notify() design. Because this is a rather large change, I'm hoping to gather thoughts and opinions from the community on this general approach before sending out a patchset. 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? Thanks, Jessica -- 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
