Lines Matching +full:system +full:- +full:on +full:- +full:module
15 There are many situations where users are reluctant to reboot a system. It may
16 be because their system is performing complex scientific computations or under
18 users want to also have a stable and secure system. Livepatching gives users
20 functions without a system reboot.
30 - The kernel probes are the most generic. The code can be redirected by
33 - The function tracer calls the code from a predefined location that is
35 compiler using the '-pg' gcc option.
37 - Livepatching typically needs to redirect the code at the very beginning
61 the same way to the rest of the system. In this case, the functions might
74 The aim is to define a so-called consistency model. It attempts to define
75 conditions when the new implementation could be used so that the system
79 kpatch: it uses kGraft's per-task consistency and syscall barrier
83 Patches are applied on a per-task basis, when the task is deemed safe to
98 tasks. If no affected functions are on the stack of a given task,
100 the tasks on the first try. Otherwise it'll keep trying
105 task is switched when it returns to user space from a system call, a
108 a) Patching I/O-bound user tasks which are sleeping on an affected
111 b) Patching CPU-bound user tasks. If the task is highly CPU-bound
121 Architectures which don't have HAVE_RELIABLE_STACKTRACE solely rely on
146 transition, it shows -1. Any tasks which are blocking the transition
148 patched state. This may be harmful to the system though. Sending a fake signal
161 Unauthorized usage may cause harm to the system. It depends on the nature of the
165 guaranteed there is no task sleeping in such module. It implies unbounded
166 reference count if a patch module is disabled and enabled in a loop.
169 patches and cause even more harm to the system. Administrator should first
174 ---------------------------------------------------------
180 for non-DWARF unwinders, also making sure there's a way for the stack
181 tracing code to detect interrupts on the stack.
188 structures are in a well-defined state.
194 There the safe location must be carefully selected on a case-by-case
198 able to use the non-stack-checking parts of the consistency model:
211 4. Livepatch module
215 samples/livepatch/livepatch-sample.c.
217 The module includes a new implementation of functions that we want
221 module is loaded. Also there is code that cleans up before the
222 livepatch module is removed. All this is explained in more details in
227 ------------------
238 relocation section in the generated livepatch module, see
239 Documentation/livepatch/module-elf-format.rst for more details.
243 -------------
248 - struct klp_func is defined for each patched function. It describes
262 only for a particular object ( vmlinux or a kernel module ). Note that
265 - struct klp_object defines an array of patched functions (struct
267 (NULL) or a module name.
275 - struct klp_patch defines an array of patched objects (struct
283 For more details on how the patch is applied on a per-task basis,
287 5. Livepatch life-cycle
295 not for the system.
299 ------------
302 module is being loaded. For this, klp_enable_patch() has to be called
305 First, only the module has an easy access to the related struct klp_patch.
307 Second, the error code might be used to refuse loading the module when
312 -------------
315 the module_init() callback. The system will start using the new
348 --------------
360 See Documentation/livepatch/cumulative-patches.rst for more details.
364 --------------
370 to the unpatched state. The system starts using either the code from
377 to '0'. All the functions (struct klp_func) associated with the to-be-disabled
386 -------------
388 Module removal is only safe when there are no users of functions provided
389 by the module. This is the reason why the force feature permanently
390 disables the removal. Only when the system is successfully transitioned
405 See Documentation/ABI/testing/sysfs-kernel-livepatch for more details.
413 - Only functions that can be traced could be patched.
415 Livepatch is based on the dynamic ftrace. In particular, functions
423 - Livepatch works reliably only when the dynamic ftrace is located at
428 using -fentry gcc compiler option on x86_64.
432 the ftrace handler. This operation has to be reverted on return.
434 this is handled on the ftrace level.
437 - Kretprobes using the ftrace framework conflict with the patched
445 - Kprobes in the original function are ignored when the code is