dynup / kpatch

kpatch - live kernel patching
GNU General Public License v2.0
1.49k stars 305 forks source link

dynrelas not being rewritten after disabling and reenabling a patch module #606

Closed flaming-toast closed 1 year ago

flaming-toast commented 8 years ago

Say we have a patch module that patches a target module X. The patch module will break/panic after the following sequence of events:

1) Load module X 2) Load patch module (dynrelas are first written) 3) Disable patch module via sysfs 4) rmmod module X 5) modprobe module X 6) Renable patch module via sysfs (dynrelas get skipped this time around because we've already modified the instructions in step 2)

Upon re-enabling the patch module, since we've written dynrelas already at step 2 we're going to end up skipping re-applying dynrelas in step 6 and we'll see the warning ("Skipping dynrela for ___ ... the instruction has been changed already"). If module X was never removed in step 4 we would still be OK since its sections/data would retain the same addresses in memory, but if we rmmod and insmod module X the addresses are different and dynrelas must be forcibly re-written.

I remember we changed the patch module's behavior to skip writing dynrelas if an instruction appears to have already been modified to accommodate paravirt instruction patching, it seems this might be an unresolvable limitation for the kpatch core module...

zhouchengming1 commented 7 years ago

Q: Is this also a problem to the livepatch core ( not the kpatch core module) ? Because we can't modify back the code when the module goes away, so later when the module comes back, livepatch won't write new dynrelas ?

github-actions[bot] commented 1 year ago

This issue has been open for 30 days with no activity and no assignee. It will be closed in 7 days unless a comment is added.

github-actions[bot] commented 1 year ago

This issue was closed because it was inactive for 7 days after being marked stale.