On Tue, Oct 15, 2019 at 03:56:34PM +0200, Peter Zijlstra wrote: > On Tue, Oct 15, 2019 at 03:07:40PM +0200, Jessica Yu wrote:
> > > Once this ftrace thing is sorted, we'll change x86 to _refuse_ to make > > > executable (kernel) memory writable. > > > > Not sure if relevant, but just thought I'd clarify: IIRC, > > klp_module_coming() is not poking the coming module, but it calls > > module_enable_ro() on itself (the livepatch module) so it can apply > > relocations and such on the new code, which lives inside the livepatch > > module, and it needs to possibly do this numerous times over the > > lifetime of the patch module for any coming module it is responsible > > for patching (i.e., call module_enable_ro() on the patch module, not > > necessarily the coming module). So I am not be sure why > > klp_module_coming() should be moved before complete_formation(). I > > hope I'm remembering the details correctly, livepatch folks feel free > > to chime in if I'm incorrect here. > > You mean it does module_disable_ro() ? That would be broken and it needs > to be fixed. Can some livepatch person explain what it does and why? mbenes confirmed; what would be needed is for the live-patch module to have all module dependent parts to be in their own section and have the sections be page-aligned. Then we can do the protection on sections instead of on the whole module. Damn, and I thought I was so close to getting W^X sorted :/
