Lines Matching +full:keep +full:- +full:a +full:- +full:live
15 There are many situations where users are reluctant to reboot a system. It may
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
31 putting a breakpoint instruction instead of any instruction.
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
44 a base. A Kprobe is registered as a ftrace handler when the function entry
46 a live patch is called with the help of a custom ftrace handler. But there are
53 Functions are there for a reason. They take some input parameters, acquire or
54 release locks, read, process, and even write some data in a defined way,
55 have return values. In other words, each function has a defined semantic.
58 example, they add a NULL pointer or a boundary check, fix a race by adding
59 a missing memory barrier, or add some locking around a critical section.
64 But there are more complex fixes. For example, a patch might change
65 ordering of locking in multiple functions at the same time. Or a patch
73 The theory about how to apply functions a safe way is rather complex.
74 The aim is to define a so-called consistency model. It attempts to define
78 Livepatch has a consistency model which is a hybrid of kGraft and
79 kpatch: it uses kGraft's per-task consistency and syscall barrier
81 a number of fallback options which make it quite flexible.
83 Patches are applied on a per-task basis, when the task is deemed safe to
84 switch over. When a patch is enabled, livepatch enters into a
86 Usually this transition state can complete in a few seconds. The same
87 sequence occurs when a patch is disabled, except the tasks converge from
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
104 2. The second approach, if needed, is kernel exit switching. A
105 task is switched when it returns to user space from a system call, a
106 user space IRQ, or a signal. It's useful in the following cases:
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
116 instead have a klp_update_patch_state() call in the idle loop which
132 The /sys/kernel/livepatch/<patch>/transition file shows whether a patch
133 is in transition. Only a single patch can be in transition at a given
134 time. A patch can remain in transition indefinitely, if any of the tasks
137 A transition can be reversed and effectively canceled by writing the
142 There's also a /proc/<pid>/patch_state file which can be used to
143 determine which tasks are blocking completion of a patching operation.
144 If a patch is in transition, this file shows 0 to indicate the task is
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
149 to all remaining blocking tasks is a better alternative. No proper signal is
154 Administrator can also affect a transition through
158 transition gets stuck for a long time because of a blocking task. Administrator
160 tasks) and request a clearance from a patch distributor to force the transition.
166 reference count if a patch module is disabled and enabled in a loop.
168 Moreover, the usage of force may also affect future applications of live
170 consider to simply cancel a transition (see above). If force is used, reboot
171 should be planned and no more live patches applied.
174 ---------------------------------------------------------
176 For adding consistency model support to new architectures, there are a
180 for non-DWARF unwinders, also making sure there's a way for the stack
183 2) Alternatively, ensure that every kthread has a call to
184 klp_update_patch_state() in a safe location. Kthreads are typically
186 location to switch the kthread's patch state would be at a designated
188 structures are in a well-defined state.
191 API. These kthreads process independent actions in a generic loop.
193 It's much more complicated with kthreads which have a custom loop.
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:
200 a) patching user tasks when they cross the kernel/user space
207 a good backup option for those architectures which don't have
215 samples/livepatch/livepatch-sample.c.
217 The module includes a new implementation of functions that we want
227 ------------------
230 sources. A good practice is to add a prefix to the names so that they
231 can be distinguished from the original ones, e.g. in a backtrace. Also
237 that may only be locally accessible. This can be solved by a special
239 Documentation/livepatch/module-elf-format.rst for more details.
243 -------------
248 - struct klp_func is defined for each patched function. It describes
249 the relation between the original and the new implementation of a
252 The structure includes the name, as a string, of the original function.
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
299 ------------
312 -------------
324 Second, livepatch enters into a transition state where tasks are converging
326 time, a function specific struct klp_ops is created and an universal
327 ftrace handler is registered\ [#]_. This stage is indicated by a value of '1'
337 is registered only once for a given function. Further patches just add
348 --------------
350 All enabled patches might get replaced by a cumulative patch that
360 See Documentation/livepatch/cumulative-patches.rst for more details.
364 --------------
369 First, livepatch enters into a transition state where tasks are converging
372 indicated by a value of '1' in /sys/kernel/livepatch/<name>/transition.
377 to '0'. All the functions (struct klp_func) associated with the to-be-disabled
386 -------------
391 to a new patch state (patched/unpatched) without being forced it is
402 /sys/kernel/livepatch/<patch>/force attributes allow administrator to affect a
405 See Documentation/ABI/testing/sysfs-kernel-livepatch for more details.
413 - Only functions that can be traced could be patched.
417 patched. Otherwise, the code would end up in an infinite loop. A
423 - Livepatch works reliably only when the dynamic ftrace is located at
428 using -fentry gcc compiler option on x86_64.
437 - Kretprobes using the ftrace framework conflict with the patched
440 Both kretprobes and livepatches use a ftrace handler that modifies
445 - Kprobes in the original function are ignored when the code is
448 There is a work in progress to add warnings about this situation.