kpatch/kmod/core/core.c

1096 lines
26 KiB
C
Raw Normal View History

/*
* Copyright (C) 2014 Seth Jennings <sjenning@redhat.com>
* Copyright (C) 2013-2014 Josh Poimboeuf <jpoimboe@redhat.com>
*
2014-03-05 03:34:03 +00:00
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, see <http://www.gnu.org/licenses/>.
2014-03-05 03:34:03 +00:00
*/
/*
* kpatch core module
*
* Patch modules register with this module to redirect old functions to new
* functions.
*
* For each function patched by the module we must:
* - Call stop_machine
* - Ensure that no task has the old function in its call stack
* - Add the new function address to kpatch_func_hash
*
2014-03-13 18:11:58 +00:00
* After that, each call to the old function calls into kpatch_ftrace_handler()
* which finds the new function in kpatch_func_hash table and updates the
2014-03-13 18:11:58 +00:00
* return instruction pointer so that ftrace will return to the new function.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/stop_machine.h>
#include <linux/ftrace.h>
#include <linux/hashtable.h>
#include <linux/hardirq.h>
#include <linux/uaccess.h>
#include <linux/kallsyms.h>
#include <asm/stacktrace.h>
#include <asm/cacheflush.h>
#include "kpatch.h"
#if !defined(CONFIG_FUNCTION_TRACER) || \
!defined(CONFIG_HAVE_FENTRY) || \
!defined(CONFIG_MODULES) || \
!defined(CONFIG_SYSFS) || \
!defined(CONFIG_KALLSYMS_ALL)
#error "CONFIG_FUNCTION_TRACER, CONFIG_HAVE_FENTRY, CONFIG_MODULES, CONFIG_SYSFS, CONFIG_KALLSYMS_ALL kernel config options are required"
#endif
#define KPATCH_HASH_BITS 8
static DEFINE_HASHTABLE(kpatch_func_hash, KPATCH_HASH_BITS);
static DEFINE_SEMAPHORE(kpatch_mutex);
LIST_HEAD(kpmod_list);
static int kpatch_num_patched;
static struct kobject *kpatch_root_kobj;
struct kobject *kpatch_patches_kobj;
EXPORT_SYMBOL_GPL(kpatch_patches_kobj);
struct kpatch_backtrace_args {
struct kpatch_module *kpmod;
int ret;
};
struct kpatch_kallsyms_args {
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
const char *name;
unsigned long addr;
};
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
/* this is a double loop, use goto instead of break */
#define do_for_each_linked_func(kpmod, func) { \
struct kpatch_object *_object; \
list_for_each_entry(_object, &kpmod->objects, list) { \
if (!kpatch_object_linked(_object)) \
continue; \
list_for_each_entry(func, &_object->funcs, list) {
#define while_for_each_linked_func() \
} \
} \
}
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
/*
* The kpatch core module has a state machine which allows for proper
* synchronization with kpatch_ftrace_handler() when it runs in NMI context.
*
* +-----------------------------------------------------+
* | |
* | +
* v +---> KPATCH_STATE_SUCCESS
* KPATCH_STATE_IDLE +---> KPATCH_STATE_UPDATING |
* ^ +---> KPATCH_STATE_FAILURE
* | +
* | |
* +-----------------------------------------------------+
*
* KPATCH_STATE_IDLE: No updates are pending. The func hash is valid, and the
* reader doesn't need to check func->op.
*
* KPATCH_STATE_UPDATING: An update is in progress. The reader must call
* kpatch_state_finish(KPATCH_STATE_FAILURE) before accessing the func hash.
*
* KPATCH_STATE_FAILURE: An update failed, and the func hash might be
* inconsistent (pending patched funcs might not have been removed yet). If
* func->op is KPATCH_OP_PATCH, then rollback to the previous version of the
* func.
*
* KPATCH_STATE_SUCCESS: An update succeeded, but the func hash might be
* inconsistent (pending unpatched funcs might not have been removed yet). If
* func->op is KPATCH_OP_UNPATCH, then rollback to the previous version of the
* func.
*/
enum {
KPATCH_STATE_IDLE,
KPATCH_STATE_UPDATING,
KPATCH_STATE_SUCCESS,
KPATCH_STATE_FAILURE,
};
static atomic_t kpatch_state;
static inline void kpatch_state_idle(void)
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
{
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
int state = atomic_read(&kpatch_state);
2014-07-14 20:49:59 +00:00
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
WARN_ON(state != KPATCH_STATE_SUCCESS && state != KPATCH_STATE_FAILURE);
atomic_set(&kpatch_state, KPATCH_STATE_IDLE);
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
}
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
static inline void kpatch_state_updating(void)
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
{
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
WARN_ON(atomic_read(&kpatch_state) != KPATCH_STATE_IDLE);
atomic_set(&kpatch_state, KPATCH_STATE_UPDATING);
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
}
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
/* If state is updating, change it to success or failure and return new state */
static inline int kpatch_state_finish(int state)
{
int result;
2014-07-14 20:49:59 +00:00
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
WARN_ON(state != KPATCH_STATE_SUCCESS && state != KPATCH_STATE_FAILURE);
result = atomic_cmpxchg(&kpatch_state, KPATCH_STATE_UPDATING, state);
return result == KPATCH_STATE_UPDATING ? state : result;
}
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
static struct kpatch_func *kpatch_get_func(unsigned long ip)
{
struct kpatch_func *f;
/* Here, we have to use rcu safe hlist because of NMI concurrency */
hash_for_each_possible_rcu(kpatch_func_hash, f, node, ip)
if (f->old_addr == ip)
return f;
return NULL;
}
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
static struct kpatch_func *kpatch_get_prev_func(struct kpatch_func *f,
unsigned long ip)
{
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
hlist_for_each_entry_continue_rcu(f, node)
if (f->old_addr == ip)
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
return f;
return NULL;
}
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
static inline bool kpatch_object_linked(struct kpatch_object *object)
{
return object->mod || !strcmp(object->name, "vmlinux");
}
static inline int kpatch_compare_addresses(unsigned long stack_addr,
unsigned long func_addr,
unsigned long func_size,
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
const char *func_name)
{
if (stack_addr >= func_addr && stack_addr < func_addr + func_size) {
pr_err("activeness safety check failed for %s\n", func_name);
return -EBUSY;
}
return 0;
}
static void kpatch_backtrace_address_verify(void *data, unsigned long address,
int reliable)
{
struct kpatch_backtrace_args *args = data;
struct kpatch_module *kpmod = args->kpmod;
struct kpatch_func *func;
int i;
if (args->ret)
return;
/* check kpmod funcs */
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
do_for_each_linked_func(kpmod, func) {
unsigned long func_addr, func_size;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
const char *func_name;
struct kpatch_func *active_func;
if (func->force)
continue;
active_func = kpatch_get_func(func->old_addr);
if (!active_func) {
/* patching an unpatched func */
func_addr = func->old_addr;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
func_size = func->old_size;
func_name = func->name;
} else {
/* repatching or unpatching */
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
func_addr = active_func->new_addr;
func_size = active_func->new_size;
func_name = active_func->name;
}
args->ret = kpatch_compare_addresses(address, func_addr,
func_size, func_name);
if (args->ret)
return;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
} while_for_each_linked_func();
/* in the replace case, need to check the func hash as well */
hash_for_each_rcu(kpatch_func_hash, i, func, node) {
if (func->op == KPATCH_OP_UNPATCH && !func->force) {
args->ret = kpatch_compare_addresses(address,
2014-07-14 20:49:59 +00:00
func->new_addr,
func->new_size,
func->name);
if (args->ret)
return;
}
}
}
static int kpatch_backtrace_stack(void *data, char *name)
{
return 0;
}
static const struct stacktrace_ops kpatch_backtrace_ops = {
.address = kpatch_backtrace_address_verify,
.stack = kpatch_backtrace_stack,
.walk_stack = print_context_stack_bp,
};
static int kpatch_print_trace_stack(void *data, char *name)
{
pr_cont(" <%s> ", name);
return 0;
}
static void kpatch_print_trace_address(void *data, unsigned long addr,
int reliable)
{
if (reliable)
pr_info("[<%p>] %pB\n", (void *)addr, (void *)addr);
}
static const struct stacktrace_ops kpatch_print_trace_ops = {
.stack = kpatch_print_trace_stack,
.address = kpatch_print_trace_address,
.walk_stack = print_context_stack,
};
/*
* Verify activeness safety, i.e. that none of the to-be-patched functions are
* on the stack of any task.
*
* This function is called from stop_machine() context.
*/
static int kpatch_verify_activeness_safety(struct kpatch_module *kpmod)
{
struct task_struct *g, *t;
int ret = 0;
struct kpatch_backtrace_args args = {
.kpmod = kpmod,
.ret = 0
};
/* Check the stacks of all tasks. */
do_each_thread(g, t) {
dump_trace(t, NULL, NULL, 0, &kpatch_backtrace_ops, &args);
if (args.ret) {
ret = args.ret;
pr_info("PID: %d Comm: %.20s\n", t->pid, t->comm);
dump_trace(t, NULL, (unsigned long *)t->thread.sp,
0, &kpatch_print_trace_ops, NULL);
goto out;
}
} while_each_thread(g, t);
out:
return ret;
}
/* Called from stop_machine */
static int kpatch_apply_patch(void *data)
{
struct kpatch_module *kpmod = data;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
struct kpatch_func *func;
struct kpatch_hook *hook;
struct kpatch_object *object;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
int ret;
ret = kpatch_verify_activeness_safety(kpmod);
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
if (ret) {
kpatch_state_finish(KPATCH_STATE_FAILURE);
return ret;
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
}
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
/* tentatively add the new funcs to the global func hash */
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
do_for_each_linked_func(kpmod, func) {
hash_add_rcu(kpatch_func_hash, &func->node, func->old_addr);
} while_for_each_linked_func();
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
/* memory barrier between func hash add and state change */
smp_wmb();
/*
* Check if any inconsistent NMI has happened while updating. If not,
* move to success state.
*/
ret = kpatch_state_finish(KPATCH_STATE_SUCCESS);
if (ret == KPATCH_STATE_FAILURE) {
pr_err("NMI activeness safety check failed\n");
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
/* Failed, we have to rollback patching process */
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
do_for_each_linked_func(kpmod, func) {
hash_del_rcu(&func->node);
} while_for_each_linked_func();
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
return -EBUSY;
}
/* run any user-defined load hooks */
list_for_each_entry(object, &kpmod->objects, list) {
if (!kpatch_object_linked(object))
continue;
list_for_each_entry(hook, &object->hooks_load, list)
(*hook->hook)();
}
return 0;
}
/* Called from stop_machine */
static int kpatch_remove_patch(void *data)
{
struct kpatch_module *kpmod = data;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
struct kpatch_func *func;
struct kpatch_hook *hook;
struct kpatch_object *object;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
int ret;
ret = kpatch_verify_activeness_safety(kpmod);
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
if (ret) {
kpatch_state_finish(KPATCH_STATE_FAILURE);
return ret;
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
}
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
/* Check if any inconsistent NMI has happened while updating */
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
ret = kpatch_state_finish(KPATCH_STATE_SUCCESS);
if (ret == KPATCH_STATE_FAILURE)
return -EBUSY;
/* Succeeded, remove all updating funcs from hash table */
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
do_for_each_linked_func(kpmod, func) {
hash_del_rcu(&func->node);
} while_for_each_linked_func();
/* run any user-defined unload hooks */
list_for_each_entry(object, &kpmod->objects, list) {
if (!kpatch_object_linked(object))
continue;
list_for_each_entry(hook, &object->hooks_unload, list)
(*hook->hook)();
}
return 0;
}
/*
* This is where the magic happens. Update regs->ip to tell ftrace to return
* to the new function.
*
* If there are multiple patch modules that have registered to patch the same
* function, the last one to register wins, as it'll be first in the hash
* bucket.
*/
static void notrace
kpatch_ftrace_handler(unsigned long ip, unsigned long parent_ip,
struct ftrace_ops *fops, struct pt_regs *regs)
{
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
struct kpatch_func *func;
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
int state;
preempt_disable_notrace();
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
if (likely(!in_nmi()))
func = kpatch_get_func(ip);
else {
/* Checking for NMI inconsistency */
state = kpatch_state_finish(KPATCH_STATE_FAILURE);
/* no memory reordering between state and func hash read */
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
smp_rmb();
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
func = kpatch_get_func(ip);
if (likely(state == KPATCH_STATE_IDLE))
goto done;
if (state == KPATCH_STATE_SUCCESS) {
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
/*
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
* Patching succeeded. If the function was being
* unpatched, roll back to the previous version.
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
*/
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
if (func && func->op == KPATCH_OP_UNPATCH)
func = kpatch_get_prev_func(func, ip);
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
} else {
/*
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
* Patching failed. If the function was being patched,
* roll back to the previous version.
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
*/
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
if (func && func->op == KPATCH_OP_PATCH)
func = kpatch_get_prev_func(func, ip);
}
}
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
done:
if (func)
regs->ip = func->new_addr + MCOUNT_INSN_SIZE;
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
preempt_enable_notrace();
}
static struct ftrace_ops kpatch_ftrace_ops __read_mostly = {
.func = kpatch_ftrace_handler,
.flags = FTRACE_OPS_FL_SAVE_REGS,
};
static int kpatch_ftrace_add_func(unsigned long ip)
{
int ret;
/* check if any other patch modules have also patched this func */
if (kpatch_get_func(ip))
return 0;
ret = ftrace_set_filter_ip(&kpatch_ftrace_ops, ip, 0, 0);
if (ret) {
pr_err("can't set ftrace filter at address 0x%lx\n", ip);
return ret;
}
if (!kpatch_num_patched) {
ret = register_ftrace_function(&kpatch_ftrace_ops);
if (ret) {
pr_err("can't register ftrace handler\n");
ftrace_set_filter_ip(&kpatch_ftrace_ops, ip, 1, 0);
return ret;
}
}
kpatch_num_patched++;
return 0;
}
static int kpatch_ftrace_remove_func(unsigned long ip)
{
int ret;
/* check if any other patch modules have also patched this func */
if (kpatch_get_func(ip))
return 0;
if (kpatch_num_patched == 1) {
ret = unregister_ftrace_function(&kpatch_ftrace_ops);
if (ret) {
pr_err("can't unregister ftrace handler\n");
return ret;
}
}
kpatch_num_patched--;
ret = ftrace_set_filter_ip(&kpatch_ftrace_ops, ip, 1, 0);
if (ret) {
pr_err("can't remove ftrace filter at address 0x%lx\n", ip);
return ret;
}
return 0;
}
static int kpatch_kallsyms_callback(void *data, const char *name,
struct module *mod,
unsigned long addr)
{
struct kpatch_kallsyms_args *args = data;
if (args->addr == addr && !strcmp(args->name, name))
return 1;
return 0;
}
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
static int kpatch_verify_symbol_match(const char *name, unsigned long addr)
{
int ret;
struct kpatch_kallsyms_args args = {
.name = name,
.addr = addr,
};
ret = kallsyms_on_each_symbol(kpatch_kallsyms_callback, &args);
if (!ret) {
pr_err("base kernel mismatch for symbol '%s'\n", name);
pr_err("expected address was 0x%016lx\n", addr);
return -EINVAL;
}
return 0;
}
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
static unsigned long kpatch_find_module_symbol(struct module *mod,
const char *name)
{
char buf[KSYM_SYMBOL_LEN];
/* check total string length for overrun */
if (strlen(mod->name) + strlen(name) + 1 >= KSYM_SYMBOL_LEN) {
pr_err("buffer overrun finding symbol '%s' in module '%s'\n",
name, mod->name);
return 0;
}
/* encode symbol name as "mod->name:name" */
strcpy(buf, mod->name);
strcat(buf, ":");
strcat(buf, name);
return kallsyms_lookup_name(buf);
}
/*
* External symbols are located outside the parent object (where the parent
* object is either vmlinux or the kmod being patched).
*/
static unsigned long kpatch_find_external_symbol(struct kpatch_module *kpmod,
const char *name)
{
const struct kernel_symbol *sym;
/* first, check if it's an exported symbol */
preempt_disable();
sym = find_symbol(name, NULL, NULL, true, true);
preempt_enable();
if (sym)
return sym->value;
/* otherwise check if it's in another .o within the patch module */
return kpatch_find_module_symbol(kpmod->mod, name);
}
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
static int kpatch_write_relocations(struct kpatch_module *kpmod,
struct kpatch_object *object)
{
int ret, size, readonly = 0, numpages;
struct kpatch_dynrela *dynrela;
u64 loc, val;
unsigned long core = (unsigned long)kpmod->mod->module_core;
unsigned long core_ro_size = kpmod->mod->core_ro_size;
unsigned long core_size = kpmod->mod->core_size;
unsigned long src;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
list_for_each_entry(dynrela, &object->dynrelas, list) {
if (!strcmp(object->name, "vmlinux")) {
ret = kpatch_verify_symbol_match(dynrela->name,
dynrela->src);
if (ret)
return ret;
} else {
/* module, dynrela->src needs to be discovered */
if (dynrela->external)
src = kpatch_find_external_symbol(kpmod,
dynrela->name);
else
src = kpatch_find_module_symbol(object->mod,
dynrela->name);
if (!src) {
pr_err("unable to find symbol '%s'\n",
dynrela->name);
return -EINVAL;
}
dynrela->src = src;
}
switch (dynrela->type) {
2014-07-14 20:49:59 +00:00
case R_X86_64_NONE:
continue;
case R_X86_64_PC32:
loc = dynrela->dest;
val = (u32)(dynrela->src + dynrela->addend -
dynrela->dest);
size = 4;
break;
case R_X86_64_32S:
loc = dynrela->dest;
val = (s32)dynrela->src + dynrela->addend;
size = 4;
break;
case R_X86_64_64:
loc = dynrela->dest;
val = dynrela->src;
size = 8;
break;
default:
pr_err("unsupported rela type %ld for source %s (0x%lx <- 0x%lx)\n",
dynrela->type, dynrela->name, dynrela->dest,
dynrela->src);
return -EINVAL;
}
if (loc >= core && loc < core + core_ro_size)
readonly = 1;
else if (loc >= core + core_ro_size && loc < core + core_size)
readonly = 0;
else {
pr_err("bad dynrela location 0x%llx for symbol %s\n",
loc, dynrela->name);
return -EINVAL;
}
numpages = (PAGE_SIZE - (loc & ~PAGE_MASK) >= size) ? 1 : 2;
if (readonly)
set_memory_rw(loc & PAGE_MASK, numpages);
ret = probe_kernel_write((void *)loc, &val, size);
if (readonly)
set_memory_ro(loc & PAGE_MASK, numpages);
if (ret) {
pr_err("write to 0x%llx failed for symbol %s\n",
loc, dynrela->name);
return ret;
}
}
return 0;
}
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
static int kpatch_unlink_object(struct kpatch_object *object)
{
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
struct kpatch_func *func;
int ret;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
list_for_each_entry(func, &object->funcs, list) {
if (!func->old_addr)
continue;
ret = kpatch_ftrace_remove_func(func->old_addr);
if (ret) {
WARN(1, "can't unregister ftrace for address 0x%lx\n",
func->old_addr);
return ret;
}
}
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
if (object->mod)
module_put(object->mod);
return 0;
}
/*
* Link to a to-be-patched object in preparation for patching it.
*
* - Find the object module
* - Write patch module relocations which reference the object
* - Calculate the patched functions' addresses
* - Register them with ftrace
*/
static int kpatch_link_object(struct kpatch_module *kpmod,
struct kpatch_object *object)
{
struct module *mod = NULL;
struct kpatch_func *func, *func_err = NULL;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
int ret;
bool vmlinux = !strcmp(object->name, "vmlinux");
if (!vmlinux) {
mutex_lock(&module_mutex);
mod = find_module(object->name);
if (!mod) {
/*
* The module hasn't been loaded yet. We can patch it
* later in kpatch_module_notify().
*/
mutex_unlock(&module_mutex);
return 0;
}
/* should never fail because we have the mutex */
WARN_ON(!try_module_get(mod));
mutex_unlock(&module_mutex);
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
object->mod = mod;
}
ret = kpatch_write_relocations(kpmod, object);
if (ret)
goto err_put;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
list_for_each_entry(func, &object->funcs, list) {
/* calculate actual old location */
if (vmlinux) {
ret = kpatch_verify_symbol_match(func->name,
func->old_addr);
if (ret) {
func_err = func;
goto err_ftrace;
}
} else {
unsigned long old_addr;
old_addr = kpatch_find_module_symbol(mod, func->name);
if (!old_addr) {
pr_err("unable to find symbol '%s' in module '%s\n",
func->name, mod->name);
func_err = func;
ret = -EINVAL;
goto err_ftrace;
}
func->old_addr = old_addr;
}
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
/* add to ftrace filter and register handler if needed */
ret = kpatch_ftrace_add_func(func->old_addr);
if (ret) {
func_err = func;
goto err_ftrace;
}
}
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
return 0;
err_ftrace:
list_for_each_entry(func, &object->funcs, list) {
if (func == func_err)
break;
WARN_ON(kpatch_ftrace_remove_func(func->old_addr));
}
err_put:
if (!vmlinux)
module_put(mod);
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
return ret;
}
static int kpatch_module_notify(struct notifier_block *nb, unsigned long action,
void *data)
{
struct module *mod = data;
struct kpatch_module *kpmod;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
struct kpatch_object *object;
struct kpatch_func *func;
struct kpatch_hook *hook;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
int ret = 0;
bool found = false;
if (action != MODULE_STATE_COMING)
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
return 0;
down(&kpatch_mutex);
list_for_each_entry(kpmod, &kpmod_list, list) {
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
list_for_each_entry(object, &kpmod->objects, list) {
if (kpatch_object_linked(object))
continue;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
if (!strcmp(object->name, mod->name)) {
found = true;
goto done;
}
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
}
}
done:
if (!found)
goto out;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
ret = kpatch_link_object(kpmod, object);
if (ret)
goto out;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
BUG_ON(!object->mod);
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
pr_notice("patching newly loaded module '%s'\n", object->name);
/* run any user-defined load hooks */
list_for_each_entry(hook, &object->hooks_load, list)
(*hook->hook)();
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
/* add to the global func hash */
list_for_each_entry(func, &object->funcs, list)
hash_add_rcu(kpatch_func_hash, &func->node, func->old_addr);
out:
up(&kpatch_mutex);
/* no way to stop the module load on error */
WARN(ret, "error (%d) patching newly loaded module '%s'\n", ret,
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
object->name);
return 0;
}
int kpatch_register(struct kpatch_module *kpmod, bool replace)
{
int ret, i, force = 0;
struct kpatch_object *object, *object_err = NULL;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
struct kpatch_func *func;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
if (!kpmod->mod || list_empty(&kpmod->objects))
return -EINVAL;
down(&kpatch_mutex);
if (kpmod->enabled) {
ret = -EINVAL;
goto err_up;
}
list_add_tail(&kpmod->list, &kpmod_list);
if (!try_module_get(kpmod->mod)) {
ret = -ENODEV;
goto err_list;
}
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
list_for_each_entry(object, &kpmod->objects, list) {
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
ret = kpatch_link_object(kpmod, object);
if (ret) {
object_err = object;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
goto err_unlink;
}
if (!kpatch_object_linked(object)) {
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
pr_notice("delaying patch of unloaded module '%s'\n",
object->name);
continue;
}
2013-01-18 18:31:14 +00:00
if (strcmp(object->name, "vmlinux"))
pr_notice("patching module '%s'\n", object->name);
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
list_for_each_entry(func, &object->funcs, list)
func->op = KPATCH_OP_PATCH;
}
if (replace)
hash_for_each_rcu(kpatch_func_hash, i, func, node)
func->op = KPATCH_OP_UNPATCH;
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
/* memory barrier between func hash and state write */
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
smp_wmb();
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
kpatch_state_updating();
/*
* Idle the CPUs, verify activeness safety, and atomically make the new
* functions visible to the ftrace handler.
*/
ret = stop_machine(kpatch_apply_patch, kpmod, NULL);
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
/*
* For the replace case, remove any obsolete funcs from the hash and
* the ftrace filter, and disable the owning patch module so that it
* can be removed.
*/
if (!ret && replace) {
struct kpatch_module *kpmod2, *safe;
hash_for_each_rcu(kpatch_func_hash, i, func, node) {
if (func->op != KPATCH_OP_UNPATCH)
continue;
if (func->force)
force = 1;
hash_del_rcu(&func->node);
WARN_ON(kpatch_ftrace_remove_func(func->old_addr));
}
list_for_each_entry_safe(kpmod2, safe, &kpmod_list, list) {
if (kpmod == kpmod2)
continue;
kpmod2->enabled = false;
pr_notice("unloaded patch module '%s'\n",
kpmod2->mod->name);
/*
* Don't allow modules with forced functions to be
* removed because they might still be in use.
*/
if (!force)
module_put(kpmod2->mod);
list_del(&kpmod2->list);
}
}
/* memory barrier between func hash and state write */
smp_wmb();
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
/* NMI handlers can return to normal now */
kpatch_state_idle();
/*
* Wait for all existing NMI handlers to complete so that they don't
* see any changes to funcs or funcs->op that might occur after this
* point.
*
* Any NMI handlers starting after this point will see the IDLE state.
*/
synchronize_rcu();
if (ret)
goto err_ops;
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
do_for_each_linked_func(kpmod, func) {
func->op = KPATCH_OP_NONE;
} while_for_each_linked_func();
/* TODO: need TAINT_KPATCH */
pr_notice_once("tainting kernel with TAINT_USER\n");
add_taint(TAINT_USER, LOCKDEP_STILL_OK);
pr_notice("loaded patch module '%s'\n", kpmod->mod->name);
kpmod->enabled = true;
up(&kpatch_mutex);
return 0;
err_ops:
if (replace)
hash_for_each_rcu(kpatch_func_hash, i, func, node)
func->op = KPATCH_OP_NONE;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
err_unlink:
list_for_each_entry(object, &kpmod->objects, list) {
if (object == object_err)
break;
if (!kpatch_object_linked(object))
continue;
2014-10-07 03:38:06 +00:00
WARN_ON(kpatch_unlink_object(object));
}
module_put(kpmod->mod);
err_list:
list_del(&kpmod->list);
err_up:
up(&kpatch_mutex);
return ret;
}
EXPORT_SYMBOL(kpatch_register);
int kpatch_unregister(struct kpatch_module *kpmod)
{
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
struct kpatch_object *object;
struct kpatch_func *func;
int ret, force = 0;
down(&kpatch_mutex);
if (!kpmod->enabled) {
ret = -EINVAL;
goto out;
}
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
do_for_each_linked_func(kpmod, func) {
func->op = KPATCH_OP_UNPATCH;
if (func->force)
force = 1;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
} while_for_each_linked_func();
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
/* memory barrier between func hash and state write */
smp_wmb();
kpatch_state_updating();
kmod/core: Support live patching on NMI handlers Support live patching on NMI handlers. This adds checks for possible inconsistency of live patching on NMI handlers. The inconsistency problem means that any concurrent execution of old function and new function, which can lead unexpected results. Current kpatch checks possible inconsistency problem with stop_machine, which can cover only threads and normal interrupts. However, beacuse NMI can not stop with it, stop_machine is not enough for live patching on NMI handlers or sub-functions which are invoked in the NMI context. To check for possible inconsistency of live patching on those functions, add an atomic flag to count patching target functions invoked in NMI context while updating kpatch hash table. If the flag is set by the target functions in NMI, we can not ensure there is no concurrent execution on it. This fixes the issue #65. Changes from v5: - Fix to add a NULL check in kpatch_get_committed_func(). Changes from v4: - Change kpatch_operation to atomic_t. - Use smp_rmb/wmb barriers between kpatch_operation and kpatch_status. - Check in_nmi() first and if true, access kpatch_operation. Changes from v3: - Fix kpatch_apply/remove_patch to return 0 if succeeded. Changes from v2: - Clean up kpatch_get_committed_func as same style of kpatch_get_func. - Rename opr to op in kpatch_ftrace_handler. - Consolidate in_nmi() and kpatch_operation check into one condition. - Fix UNPATCH/PATCH mistype in kpatch_register. Changes from v1: - Rename inconsistent_flag to kpatch_status. - Introduce new enums and helper functions for kpatch_status. - Use hash_del_rcu instead of hlist_del_rcu. - Rename get_committed_func to kpatch_get_committed_func. - Use ACCESS_ONCE for kpatch_operation to prevent compiler optimization. - Fix to remove (!func || func->updating) condition from NMI check. - Add more precise comments. - Fix setting order of kpatch_status and kpatch_operation. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-04-23 01:58:45 +00:00
ret = stop_machine(kpatch_remove_patch, kpmod, NULL);
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
/* NMI handlers can return to normal now */
kpatch_state_idle();
/*
* Wait for all existing NMI handlers to complete so that they don't
* see any changes to funcs or funcs->op that might occur after this
* point.
*
* Any NMI handlers starting after this point will see the IDLE state.
*/
synchronize_rcu();
if (ret) {
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
do_for_each_linked_func(kpmod, func) {
func->op = KPATCH_OP_NONE;
} while_for_each_linked_func();
goto out;
kmod/core: NMI synchronization improvements This is an attempt to both simplify and improve the correctness of the NMI synchronization code. There's a race in kpatch_ftrace_handler() between the kpatch_get_func() and kpatch_finish_status() calls which could result in func being NULL. The retry was supposed to fix this. However, this race would still be a problem in the repatching case (if the function had already been previously patched), in which case func would not be NULL, but could instead point to the previously patched version of the function. In this case it wouldn't retry and it would be possible for the previous version of the function to run. The fix is to use a memory barrier between accesses of the func hash and the status variable, and then just call kpatch_get_func() *after* accessing the status variable. For OP_PATCH, if status is SUCCESS, then func is guaranteed to point to the new function. If status is FAILURE, func might point to the new function, in which case we can use get_prev_func to get the previous version of the function. I also made some pretty big changes to try to simplify the design so that there are less moving parts and so that it's hopefully easier to understand. I moved the OP field into the kpatch_func struct. This allows us to merge the two global state variables (status + op) into a single global state variable (state), which helps make the code quite a bit simpler. I turned it into a proper state machine and documented the meaning of each state in the comments. Moving the OP field to the kpatch_func struct also paves the way for an upcoming pull request which will allow patch modules to be atomically replaced ("kpatch load --replace <module>").
2014-04-28 16:41:20 +00:00
}
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
list_for_each_entry(object, &kpmod->objects, list) {
if (!kpatch_object_linked(object))
continue;
implement per-object patching/relocations The recent module patching code has exposed some problems with our data structures. We currently patch the funcs and dynrelas individually, which is kind of scary now that different objects can be patched at different times. Instead it's cleaner and safer to group them by patched object. This patch implements per-object patching and relocations by refactoring the interfaces: - Completely separate the create-diff-object <-> patch module interface from the patch module <-> core module interface. create-diff-object will include "kpatch-patch.h" but not "kpatch.h". Thus, create-diff-object has no knowledge about the core module's interfaces, and the core module has no knowledge about the patch module's special sections. - Newly added kpatch-patch.h defines the format of the patch module special sections. It's used by create-diff-object to create the special sections and used by the patch module to read them. - kpatch.h still defines the core module interfaces. Each kpatch_module has a list of kpatch_objects for each module object to be patched. Each kpatch_object has a list of kpatch_funcs and a list of kpatch_dynrelas. The patch module creates these lists when populating kpatch_module. This way of structuring the data allows us to patch funcs and dynrelas on a per patched object basis, which will allow us to catch more error scenarios and make the code easier to manage going forward. It also allows the use of much more common code between kpatch_register() and kpatch_module_notify().
2014-06-17 14:51:47 +00:00
ret = kpatch_unlink_object(object);
if (ret)
goto out;
}
pr_notice("unloaded patch module '%s'\n", kpmod->mod->name);
kpmod->enabled = false;
/*
* Don't allow modules with forced functions to be removed because they
* might still be in use.
*/
if (!force)
module_put(kpmod->mod);
list_del(&kpmod->list);
out:
up(&kpatch_mutex);
return ret;
}
EXPORT_SYMBOL(kpatch_unregister);
static struct notifier_block kpatch_module_nb = {
.notifier_call = kpatch_module_notify,
.priority = INT_MIN, /* called last */
};
static int kpatch_init(void)
{
int ret;
kpatch_root_kobj = kobject_create_and_add("kpatch", kernel_kobj);
if (!kpatch_root_kobj)
return -ENOMEM;
kpatch_patches_kobj = kobject_create_and_add("patches",
kpatch_root_kobj);
if (!kpatch_patches_kobj) {
ret = -ENOMEM;
goto err_root_kobj;
}
ret = register_module_notifier(&kpatch_module_nb);
if (ret)
goto err_patches_kobj;
return 0;
err_patches_kobj:
kobject_put(kpatch_patches_kobj);
err_root_kobj:
kobject_put(kpatch_root_kobj);
return ret;
}
static void kpatch_exit(void)
{
WARN_ON(kpatch_num_patched != 0);
WARN_ON(unregister_module_notifier(&kpatch_module_nb));
kobject_put(kpatch_patches_kobj);
kobject_put(kpatch_root_kobj);
}
module_init(kpatch_init);
module_exit(kpatch_exit);
MODULE_LICENSE("GPL");