RepoMirrors
/
kpatch
mirror of https://github.com/dynup/kpatch
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
kpatch/kmod/core/kpatch.h

88 lines
2.0 KiB
C
Raw Normal View History

add documentation to core kmod files Signed-off-by: Seth Jennings <sjenning@redhat.com>
2014-02-11 20:01:00 +00:00
/*
* kpatch.h
*
* Copyright (C) 2014 Seth Jennings <sjenning@redhat.com>
kmod/core: remove unused old_func_name field Not needed, we can always add it again later if needed (for sanity checks, maybe)
2014-03-13 20:08:08 +00:00
* Copyright (C) 2013-2014 Josh Poimboeuf <jpoimboe@redhat.com>
add documentation to core kmod files Signed-off-by: Seth Jennings <sjenning@redhat.com>
2014-02-11 20:01:00 +00:00
*
add GPLv2 headers to source files
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
kmod/core: checkpatch and sparse fixes - checkpatch doesn't like the FSF address since it's subject to change - checkpatch doesn't like strings split by line - whitespace fix - sparse suggested to change some variables and functions to static
2014-05-01 17:19:41 +00:00
* along with this program; if not, see <https://www.gnu.org/licenses/>.
add GPLv2 headers to source files
2014-03-05 03:34:03 +00:00
*
use consistent naming for core and patch modules
2014-02-13 16:51:00 +00:00
* Contains the API for the core kpatch module used by the patch modules
add documentation to core kmod files Signed-off-by: Seth Jennings <sjenning@redhat.com>
2014-02-11 20:01:00 +00:00
*/
major rewrite to per-section function/data model Signed-off-by: Seth Jennings <sjenning@redhat.com>
2014-02-11 16:25:48 +00:00
#ifndef _KPATCH_H_
#define _KPATCH_H_
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
#include <linux/types.h>
#include <linux/module.h>
enum kpatch_op {
KPATCH_OP_NONE,
KPATCH_OP_PATCH,
KPATCH_OP_UNPATCH,
};
struct kpatch_func {
/* public */
kmod/core: rename some variables For the sake of consistency and readability, rename some variables. Also change func->old_addr_end to func->old_size.
2014-03-14 18:22:59 +00:00
unsigned long new_addr;
fix activeness safety check when unpatching When unpatching, the activeness safety logic should check for the new function on the stack, not the old one. Fixes #64.
2014-04-21 16:49:58 +00:00
unsigned long new_size;
change struct kpatch_patch s/old_addr/old_offset Make old addresses relative to the start address of the relocatable kernel or module. This commit has no functional effect; it just prepares the code for future acceptance of the module patching support. Signed-off-by: Seth Jennings <sjenning@redhat.com>
2014-06-02 19:46:35 +00:00
unsigned long old_offset;
kmod/core: rename some variables For the sake of consistency and readability, rename some variables. Also change func->old_addr_end to func->old_size.
2014-03-14 18:22:59 +00:00
unsigned long old_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 *name;
struct list_head list;
/* private */
struct hlist_node node;
unsigned long old_addr;
enum kpatch_op op;
major rewrite to per-section function/data model Signed-off-by: Seth Jennings <sjenning@redhat.com>
2014-02-11 16:25:48 +00:00
};
dynrelas support, obsoleting link-vmlinux-syms This adds dynamic linking support for the patch modules. It is the first step toward supporting patching module code and relocatable kernels. Rela entries that reference non-included local and non-exported global symbols are converted to "dynrelas". These dynrelas are relocations that are done by the core module, not the kernel module linker. This allows the core module to apply offsets to the base addresses found in the base vmlinux or module. Signed-off-by: Seth Jennings <sjenning@redhat.com> Conflicts: kpatch-build/kpatch-build
2014-05-14 20:59:05 +00:00
struct kpatch_dynrela {
unsigned long dest;
unsigned long src;
unsigned long type;
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;
symbol location verification support This commit introduces functionality to verify the location of symbols used in both the patch and dynrelas sections. It adds significant protection from mismatches between the base and running kernels. Signed-off-by: Seth Jennings <sjenning@redhat.com>
2014-05-23 21:36:31 +00:00
int addend;
fix undefined symbols for future loaded modules When patching module A, if one of the new function's relas reference a symbol in module B, we currently just leave it as a normal rela. But if module B hasn't been loaded yet, the patch module will fail to load due to the rela's reference to an undefined symbol. The fix is to convert these relas to dynrelas, which can be resolved later in the module notifier when A is loaded. Also added support for the R_X86_64_NONE relocation type, needed for dynrelas which reference __fentry__.
2014-06-18 14:48:51 +00:00
bool exported;
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 list_head list;
dynrelas support, obsoleting link-vmlinux-syms This adds dynamic linking support for the patch modules. It is the first step toward supporting patching module code and relocatable kernels. Rela entries that reference non-included local and non-exported global symbols are converted to "dynrelas". These dynrelas are relocations that are done by the core module, not the kernel module linker. This allows the core module to apply offsets to the base addresses found in the base vmlinux or module. Signed-off-by: Seth Jennings <sjenning@redhat.com> Conflicts: kpatch-build/kpatch-build
2014-05-14 20:59:05 +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
struct kpatch_object {
struct list_head list;
const char *name;
struct list_head funcs;
struct list_head dynrelas;
refactor core <-> patch interface Make kpatch_funs truly internal by: Defining it in core.c Adding a struct kpatch_internal, declared in kpatch.h and defined in core.c, that contains per patch module internal data. Adding an "internal" field to struct kpatch_modules. Allocating internal and funcs data in core.c, not in the patch module, since the patch module has no knowledge of kpatch_func anymore. Adding a "patch" field to kpatch_func that points directly to the kpatch_patch provided by the module (rather than a field-by-field copy) Signed-off-by: Seth Jennings <sjenning@redhat.com>
2014-05-12 19:36:10 +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
/* private */
struct module *mod;
};
refactor core <-> patch interface Make kpatch_funs truly internal by: Defining it in core.c Adding a struct kpatch_internal, declared in kpatch.h and defined in core.c, that contains per patch module internal data. Adding an "internal" field to struct kpatch_modules. Allocating internal and funcs data in core.c, not in the patch module, since the patch module has no knowledge of kpatch_func anymore. Adding a "patch" field to kpatch_func that points directly to the kpatch_patch provided by the module (rather than a field-by-field copy) Signed-off-by: Seth Jennings <sjenning@redhat.com>
2014-05-12 19:36:10 +00:00
kmod: add new kpatch_module struct Put funcs, num_funcs, and mod in their own struct called kpatch_module. This allows us to keep patch module specific variables in one place (and we'll have more of these variables soon).
2014-04-21 16:29:01 +00:00
struct kpatch_module {
kmod/core: get rid of kpatch_internal The kpatch_internal struct is a good idea, in that it documents which parts of kpatch_module shouldn't be used by the patch module. But it creates extra code and will require more extra code if we want to keep a list of kpmods, which is needed to create a module notifier for module patching of future loaded modules. Embedding the private data directly in the public struct allows the code to be simpler: no extra kmallocs/kfrees, no need to store pointers between the public and private structs. I think the simpler code is worth the tradeoff (exposing implementation detail). Kernel code usually doesn't bother with hiding a internal struct data from other kernel code anyway. For example, see ftrace_ops or struct kprobe. The private fields are documented with a "private" comment.
2014-06-10 17:02:34 +00:00
/* public */
kmod: add new kpatch_module struct Put funcs, num_funcs, and mod in their own struct called kpatch_module. This allows us to keep patch module specific variables in one place (and we'll have more of these variables soon).
2014-04-21 16:29:01 +00:00
struct module *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
struct list_head objects;
/* public read-only */
safe kpatch unload Currently the patch module calls kpatch_unregister in the patch module exit path. If the activeness safety check fails in kpatch_unregister, it's too late for the patch module to stop exiting, so all it can do is panic. Prevent this scenario by requiring the user to disable the patch module via sysfs before allowing the module to be unloaded. The sysfs write will fail if the activeness safety check fails. An rmmod will fail if the patch is still enabled. Also add support for this new unloading model in "kpatch unload".
2014-04-26 04:05:26 +00:00
bool enabled;
kmod/core: get rid of kpatch_internal The kpatch_internal struct is a good idea, in that it documents which parts of kpatch_module shouldn't be used by the patch module. But it creates extra code and will require more extra code if we want to keep a list of kpmods, which is needed to create a module notifier for module patching of future loaded modules. Embedding the private data directly in the public struct allows the code to be simpler: no extra kmallocs/kfrees, no need to store pointers between the public and private structs. I think the simpler code is worth the tradeoff (exposing implementation detail). Kernel code usually doesn't bother with hiding a internal struct data from other kernel code anyway. For example, see ftrace_ops or struct kprobe. The private fields are documented with a "private" comment.
2014-06-10 17:02:34 +00:00
/* private */
kmod/core: create global kpmod_list Create a list of registered patch modules, which will be used in the module notifier to patch future loaded modules. It will also be used to fix the kpatch replace race condition where it calls module_put too early.
2014-06-10 17:28:40 +00:00
struct list_head list;
kmod: add new kpatch_module struct Put funcs, num_funcs, and mod in their own struct called kpatch_module. This allows us to keep patch module specific variables in one place (and we'll have more of these variables soon).
2014-04-21 16:29:01 +00:00
};
safe kpatch unload Currently the patch module calls kpatch_unregister in the patch module exit path. If the activeness safety check fails in kpatch_unregister, it's too late for the patch module to stop exiting, so all it can do is panic. Prevent this scenario by requiring the user to disable the patch module via sysfs before allowing the module to be unloaded. The sysfs write will fail if the activeness safety check fails. An rmmod will fail if the patch is still enabled. Also add support for this new unloading model in "kpatch unload".
2014-04-26 04:05:26 +00:00
extern struct kobject *kpatch_patches_kobj;
kpatch replace Allow the user to atomically replace all existing modules with a new "kpatch replace" command. This provides a safe way to do atomic upgrades for cumulative patch module updates.
2014-04-28 21:18:29 +00:00
extern int kpatch_register(struct kpatch_module *kpmod, bool replace);
kmod: add new kpatch_module struct Put funcs, num_funcs, and mod in their own struct called kpatch_module. This allows us to keep patch module specific variables in one place (and we'll have more of these variables soon).
2014-04-21 16:29:01 +00:00
extern int kpatch_unregister(struct kpatch_module *kpmod);
major rewrite to per-section function/data model Signed-off-by: Seth Jennings <sjenning@redhat.com>
2014-02-11 16:25:48 +00:00
#endif /* _KPATCH_H_ */