Lines Matching +full:system +full:- +full:on +full:- +full:module
12 4. Livepatch module
15 5. Livepatch life-cycle
28 There are many situations where users are reluctant to reboot a system. It may
29 be because their system is performing complex scientific computations or under
31 users want to also have a stable and secure system. Livepatching gives users
33 functions without a system reboot.
43 - The kernel probes are the most generic. The code can be redirected by
46 - The function tracer calls the code from a predefined location that is
48 compiler using the '-pg' gcc option.
50 - Livepatching typically needs to redirect the code at the very beginning
74 the same way to the rest of the system. In this case, the functions might
87 The aim is to define a so-called consistency model. It attempts to define
88 conditions when the new implementation could be used so that the system
92 kpatch: it uses kGraft's per-task consistency and syscall barrier
96 Patches are applied on a per-task basis, when the task is deemed safe to
111 tasks. If no affected functions are on the stack of a given task,
113 the tasks on the first try. Otherwise it'll keep trying
118 task is switched when it returns to user space from a system call, a
121 a) Patching I/O-bound user tasks which are sleeping on an affected
124 b) Patching CPU-bound user tasks. If the task is highly CPU-bound
134 Architectures which don't have HAVE_RELIABLE_STACKTRACE solely rely on
159 transition, it shows -1. Any tasks which are blocking the transition
161 patched state. This may be harmful to the system though. Sending a fake signal
174 Unauthorized usage may cause harm to the system. It depends on the nature of the
178 guaranteed there is no task sleeping in such module. It implies unbounded
179 reference count if a patch module is disabled and enabled in a loop.
182 patches and cause even more harm to the system. Administrator should first
187 ---------------------------------------------------------
193 for non-DWARF unwinders, also making sure there's a way for the stack
194 tracing code to detect interrupts on the stack.
201 structures are in a well-defined state.
207 There the safe location must be carefully selected on a case-by-case
211 able to use the non-stack-checking parts of the consistency model:
224 4. Livepatch module
228 samples/livepatch/livepatch-sample.c.
230 The module includes a new implementation of functions that we want
234 module is loaded. Also there is code that cleans up before the
235 livepatch module is removed. All this is explained in more details in
240 ------------------
251 relocation section in the generated livepatch module, see
252 Documentation/livepatch/module-elf-format.rst for more details.
256 -------------
261 - struct klp_func is defined for each patched function. It describes
275 only for a particular object ( vmlinux or a kernel module ). Note that
278 - struct klp_object defines an array of patched functions (struct
280 (NULL) or a module name.
288 - struct klp_patch defines an array of patched objects (struct
296 For more details on how the patch is applied on a per-task basis,
300 5. Livepatch life-cycle
308 not for the system.
312 ------------
315 module is being loaded. For this, klp_enable_patch() has to be called
318 First, only the module has an easy access to the related struct klp_patch.
320 Second, the error code might be used to refuse loading the module when
325 -------------
328 the module_init() callback. The system will start using the new
361 --------------
373 See Documentation/livepatch/cumulative-patches.rst for more details.
377 --------------
383 to the unpatched state. The system starts using either the code from
390 to '0'. All the functions (struct klp_func) associated with the to-be-disabled
399 -------------
401 Module removal is only safe when there are no users of functions provided
402 by the module. This is the reason why the force feature permanently
403 disables the removal. Only when the system is successfully transitioned
418 See Documentation/ABI/testing/sysfs-kernel-livepatch for more details.
426 - Only functions that can be traced could be patched.
428 Livepatch is based on the dynamic ftrace. In particular, functions
436 - Livepatch works reliably only when the dynamic ftrace is located at
441 using -fentry gcc compiler option on x86_64.
445 the ftrace handler. This operation has to be reverted on return.
447 this is handled on the ftrace level.
450 - Kretprobes using the ftrace framework conflict with the patched
458 - Kprobes in the original function are ignored when the code is