[ live-patching ML CCed ] On Tue, 15 Oct 2019, Peter Zijlstra wrote:
> On Tue, Oct 15, 2019 at 03:07:40PM +0200, Jessica Yu wrote: > > > > The fact that it is executable; also the fact that you do it right after > > > we mark it ro. Flipping the memory protections back and forth is just > > > really poor everything. > > > > > > 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? Yes, it does. klp_module_coming() calls module_disable_ro() on all patching modules which patch the coming module in order to call apply_relocate_add(). New (patching) code for a module can be relocated only when the relevant module is loaded. Miroslav
