Skip to content

Commit d0807da

Browse files
mirabJiri Kosina
authored andcommitted
livepatch: Remove immediate feature
Immediate flag has been used to disable per-task consistency and patch all tasks immediately. It could be useful if the patch doesn't change any function or data semantics. However, it causes problems on its own. The consistency problem is currently broken with respect to immediate patches. func a patches 1i 2i 3 When the patch 3 is applied, only 2i function is checked (by stack checking facility). There might be a task sleeping in 1i though. Such task is migrated to 3, because we do not check 1i in klp_check_stack_func() at all. Coming atomic replace feature would be easier to implement and more reliable without immediate. Thus, remove immediate feature completely and save us from the problems. Note that force feature has the similar problem. However it is considered as a last resort. If used, administrator should not apply any new live patches and should plan for reboot into an updated kernel. The architectures would now need to provide HAVE_RELIABLE_STACKTRACE to fully support livepatch. Signed-off-by: Miroslav Benes <mbenes@suse.cz> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
1 parent c99a2be commit d0807da

File tree

8 files changed

+33
-181
lines changed

8 files changed

+33
-181
lines changed

Documentation/livepatch/livepatch.txt

Lines changed: 27 additions & 62 deletions
Original file line numberDiff line numberDiff line change
@@ -72,8 +72,7 @@ example, they add a NULL pointer or a boundary check, fix a race by adding
7272
a missing memory barrier, or add some locking around a critical section.
7373
Most of these changes are self contained and the function presents itself
7474
the same way to the rest of the system. In this case, the functions might
75-
be updated independently one by one. (This can be done by setting the
76-
'immediate' flag in the klp_patch struct.)
75+
be updated independently one by one.
7776

7877
But there are more complex fixes. For example, a patch might change
7978
ordering of locking in multiple functions at the same time. Or a patch
@@ -125,40 +124,23 @@ safe to patch tasks:
125124
b) Patching CPU-bound user tasks. If the task is highly CPU-bound
126125
then it will get patched the next time it gets interrupted by an
127126
IRQ.
128-
c) In the future it could be useful for applying patches for
129-
architectures which don't yet have HAVE_RELIABLE_STACKTRACE. In
130-
this case you would have to signal most of the tasks on the
131-
system. However this isn't supported yet because there's
132-
currently no way to patch kthreads without
133-
HAVE_RELIABLE_STACKTRACE.
134127

135128
3. For idle "swapper" tasks, since they don't ever exit the kernel, they
136129
instead have a klp_update_patch_state() call in the idle loop which
137130
allows them to be patched before the CPU enters the idle state.
138131

139132
(Note there's not yet such an approach for kthreads.)
140133

141-
All the above approaches may be skipped by setting the 'immediate' flag
142-
in the 'klp_patch' struct, which will disable per-task consistency and
143-
patch all tasks immediately. This can be useful if the patch doesn't
144-
change any function or data semantics. Note that, even with this flag
145-
set, it's possible that some tasks may still be running with an old
146-
version of the function, until that function returns.
134+
Architectures which don't have HAVE_RELIABLE_STACKTRACE solely rely on
135+
the second approach. It's highly likely that some tasks may still be
136+
running with an old version of the function, until that function
137+
returns. In this case you would have to signal the tasks. This
138+
especially applies to kthreads. They may not be woken up and would need
139+
to be forced. See below for more information.
147140

148-
There's also an 'immediate' flag in the 'klp_func' struct which allows
149-
you to specify that certain functions in the patch can be applied
150-
without per-task consistency. This might be useful if you want to patch
151-
a common function like schedule(), and the function change doesn't need
152-
consistency but the rest of the patch does.
153-
154-
For architectures which don't have HAVE_RELIABLE_STACKTRACE, the user
155-
must set patch->immediate which causes all tasks to be patched
156-
immediately. This option should be used with care, only when the patch
157-
doesn't change any function or data semantics.
158-
159-
In the future, architectures which don't have HAVE_RELIABLE_STACKTRACE
160-
may be allowed to use per-task consistency if we can come up with
161-
another way to patch kthreads.
141+
Unless we can come up with another way to patch kthreads, architectures
142+
without HAVE_RELIABLE_STACKTRACE are not considered fully supported by
143+
the kernel livepatching.
162144

163145
The /sys/kernel/livepatch/<patch>/transition file shows whether a patch
164146
is in transition. Only a single patch (the topmost patch on the stack)
@@ -197,6 +179,11 @@ modules is permanently disabled when the force feature is used. It cannot be
197179
guaranteed there is no task sleeping in such module. It implies unbounded
198180
reference count if a patch module is disabled and enabled in a loop.
199181

182+
Moreover, the usage of force may also affect future applications of live
183+
patches and cause even more harm to the system. Administrator should first
184+
consider to simply cancel a transition (see above). If force is used, reboot
185+
should be planned and no more live patches applied.
186+
200187
3.1 Adding consistency model support to new architectures
201188
---------------------------------------------------------
202189

@@ -234,13 +221,6 @@ few options:
234221
a good backup option for those architectures which don't have
235222
reliable stack traces yet.
236223

237-
In the meantime, patches for such architectures can bypass the
238-
consistency model by setting klp_patch.immediate to true. This option
239-
is perfectly fine for patches which don't change the semantics of the
240-
patched functions. In practice, this is usable for ~90% of security
241-
fixes. Use of this option also means the patch can't be unloaded after
242-
it has been disabled.
243-
244224

245225
4. Livepatch module
246226
===================
@@ -296,9 +276,6 @@ into three levels:
296276
only for a particular object ( vmlinux or a kernel module ). Note that
297277
kallsyms allows for searching symbols according to the object name.
298278

299-
There's also an 'immediate' flag which, when set, patches the
300-
function immediately, bypassing the consistency model safety checks.
301-
302279
+ struct klp_object defines an array of patched functions (struct
303280
klp_func) in the same object. Where the object is either vmlinux
304281
(NULL) or a module name.
@@ -317,9 +294,6 @@ into three levels:
317294
symbols are found. The only exception are symbols from objects
318295
(kernel modules) that have not been loaded yet.
319296

320-
Setting the 'immediate' flag applies the patch to all tasks
321-
immediately, bypassing the consistency model safety checks.
322-
323297
For more details on how the patch is applied on a per-task basis,
324298
see the "Consistency model" section.
325299

@@ -334,14 +308,12 @@ section "Livepatch life-cycle" below for more details about these
334308
two operations.
335309

336310
Module removal is only safe when there are no users of the underlying
337-
functions. The immediate consistency model is not able to detect this. The
338-
code just redirects the functions at the very beginning and it does not
339-
check if the functions are in use. In other words, it knows when the
340-
functions get called but it does not know when the functions return.
341-
Therefore it cannot be decided when the livepatch module can be safely
342-
removed. This is solved by a hybrid consistency model. When the system is
343-
transitioned to a new patch state (patched/unpatched) it is guaranteed that
344-
no task sleeps or runs in the old code.
311+
functions. This is the reason why the force feature permanently disables
312+
the removal. The forced tasks entered the functions but we cannot say
313+
that they returned back. Therefore it cannot be decided when the
314+
livepatch module can be safely removed. When the system is successfully
315+
transitioned to a new patch state (patched/unpatched) without being
316+
forced it is guaranteed that no task sleeps or runs in the old code.
345317

346318

347319
5. Livepatch life-cycle
@@ -355,19 +327,12 @@ First, the patch is applied only when all patched symbols for already
355327
loaded objects are found. The error handling is much easier if this
356328
check is done before particular functions get redirected.
357329

358-
Second, the immediate consistency model does not guarantee that anyone is not
359-
sleeping in the new code after the patch is reverted. This means that the new
360-
code needs to stay around "forever". If the code is there, one could apply it
361-
again. Therefore it makes sense to separate the operations that might be done
362-
once and those that need to be repeated when the patch is enabled (applied)
363-
again.
364-
365-
Third, it might take some time until the entire system is migrated
366-
when a more complex consistency model is used. The patch revert might
367-
block the livepatch module removal for too long. Therefore it is useful
368-
to revert the patch using a separate operation that might be called
369-
explicitly. But it does not make sense to remove all information
370-
until the livepatch module is really removed.
330+
Second, it might take some time until the entire system is migrated with
331+
the hybrid consistency model being used. The patch revert might block
332+
the livepatch module removal for too long. Therefore it is useful to
333+
revert the patch using a separate operation that might be called
334+
explicitly. But it does not make sense to remove all information until
335+
the livepatch module is really removed.
371336

372337

373338
5.1. Registration

include/linux/livepatch.h

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -40,7 +40,6 @@
4040
* @new_func: pointer to the patched function code
4141
* @old_sympos: a hint indicating which symbol position the old function
4242
* can be found (optional)
43-
* @immediate: patch the func immediately, bypassing safety mechanisms
4443
* @old_addr: the address of the function being patched
4544
* @kobj: kobject for sysfs resources
4645
* @stack_node: list node for klp_ops func_stack list
@@ -76,7 +75,6 @@ struct klp_func {
7675
* in kallsyms for the given object is used.
7776
*/
7877
unsigned long old_sympos;
79-
bool immediate;
8078

8179
/* internal */
8280
unsigned long old_addr;
@@ -137,7 +135,6 @@ struct klp_object {
137135
* struct klp_patch - patch structure for live patching
138136
* @mod: reference to the live patch module
139137
* @objs: object entries for kernel objects to be patched
140-
* @immediate: patch all funcs immediately, bypassing safety mechanisms
141138
* @list: list node for global list of registered patches
142139
* @kobj: kobject for sysfs resources
143140
* @enabled: the patch is enabled (but operation may be incomplete)
@@ -147,7 +144,6 @@ struct klp_patch {
147144
/* external */
148145
struct module *mod;
149146
struct klp_object *objs;
150-
bool immediate;
151147

152148
/* internal */
153149
struct list_head list;

kernel/livepatch/core.c

Lines changed: 1 addition & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -366,11 +366,6 @@ static int __klp_enable_patch(struct klp_patch *patch)
366366
/*
367367
* A reference is taken on the patch module to prevent it from being
368368
* unloaded.
369-
*
370-
* Note: For immediate (no consistency model) patches we don't allow
371-
* patch modules to unload since there is no safe/sane method to
372-
* determine if a thread is still running in the patched code contained
373-
* in the patch module once the ftrace registration is successful.
374369
*/
375370
if (!try_module_get(patch->mod))
376371
return -ENODEV;
@@ -890,12 +885,7 @@ int klp_register_patch(struct klp_patch *patch)
890885
if (!klp_initialized())
891886
return -ENODEV;
892887

893-
/*
894-
* Architectures without reliable stack traces have to set
895-
* patch->immediate because there's currently no way to patch kthreads
896-
* with the consistency model.
897-
*/
898-
if (!klp_have_reliable_stack() && !patch->immediate) {
888+
if (!klp_have_reliable_stack()) {
899889
pr_err("This architecture doesn't have support for the livepatch consistency model.\n");
900890
return -ENOSYS;
901891
}

kernel/livepatch/transition.c

Lines changed: 5 additions & 44 deletions
Original file line numberDiff line numberDiff line change
@@ -82,7 +82,6 @@ static void klp_complete_transition(void)
8282
struct klp_func *func;
8383
struct task_struct *g, *task;
8484
unsigned int cpu;
85-
bool immediate_func = false;
8685

8786
pr_debug("'%s': completing %s transition\n",
8887
klp_transition_patch->mod->name,
@@ -104,16 +103,9 @@ static void klp_complete_transition(void)
104103
klp_synchronize_transition();
105104
}
106105

107-
if (klp_transition_patch->immediate)
108-
goto done;
109-
110-
klp_for_each_object(klp_transition_patch, obj) {
111-
klp_for_each_func(obj, func) {
106+
klp_for_each_object(klp_transition_patch, obj)
107+
klp_for_each_func(obj, func)
112108
func->transition = false;
113-
if (func->immediate)
114-
immediate_func = true;
115-
}
116-
}
117109

118110
/* Prevent klp_ftrace_handler() from seeing KLP_UNDEFINED state */
119111
if (klp_target_state == KLP_PATCHED)
@@ -132,7 +124,6 @@ static void klp_complete_transition(void)
132124
task->patch_state = KLP_UNDEFINED;
133125
}
134126

135-
done:
136127
klp_for_each_object(klp_transition_patch, obj) {
137128
if (!klp_is_object_loaded(obj))
138129
continue;
@@ -146,16 +137,11 @@ static void klp_complete_transition(void)
146137
klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
147138

148139
/*
149-
* See complementary comment in __klp_enable_patch() for why we
150-
* keep the module reference for immediate patches.
151-
*
152-
* klp_forced or immediate_func set implies unbounded increase of
153-
* module's ref count if the module is disabled/enabled in a loop.
140+
* klp_forced set implies unbounded increase of module's ref count if
141+
* the module is disabled/enabled in a loop.
154142
*/
155-
if (!klp_forced && !klp_transition_patch->immediate &&
156-
!immediate_func && klp_target_state == KLP_UNPATCHED) {
143+
if (!klp_forced && klp_target_state == KLP_UNPATCHED)
157144
module_put(klp_transition_patch->mod);
158-
}
159145

160146
klp_target_state = KLP_UNDEFINED;
161147
klp_transition_patch = NULL;
@@ -223,9 +209,6 @@ static int klp_check_stack_func(struct klp_func *func,
223209
struct klp_ops *ops;
224210
int i;
225211

226-
if (func->immediate)
227-
return 0;
228-
229212
for (i = 0; i < trace->nr_entries; i++) {
230213
address = trace->entries[i];
231214

@@ -387,13 +370,6 @@ void klp_try_complete_transition(void)
387370

388371
WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
389372

390-
/*
391-
* If the patch can be applied or reverted immediately, skip the
392-
* per-task transitions.
393-
*/
394-
if (klp_transition_patch->immediate)
395-
goto success;
396-
397373
/*
398374
* Try to switch the tasks to the target patch state by walking their
399375
* stacks and looking for any to-be-patched or to-be-unpatched
@@ -437,7 +413,6 @@ void klp_try_complete_transition(void)
437413
return;
438414
}
439415

440-
success:
441416
/* we're done, now cleanup the data structures */
442417
klp_complete_transition();
443418
}
@@ -457,13 +432,6 @@ void klp_start_transition(void)
457432
klp_transition_patch->mod->name,
458433
klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
459434

460-
/*
461-
* If the patch can be applied or reverted immediately, skip the
462-
* per-task transitions.
463-
*/
464-
if (klp_transition_patch->immediate)
465-
return;
466-
467435
/*
468436
* Mark all normal tasks as needing a patch state update. They'll
469437
* switch either in klp_try_complete_transition() or as they exit the
@@ -513,13 +481,6 @@ void klp_init_transition(struct klp_patch *patch, int state)
513481
pr_debug("'%s': initializing %s transition\n", patch->mod->name,
514482
klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
515483

516-
/*
517-
* If the patch can be applied or reverted immediately, skip the
518-
* per-task transitions.
519-
*/
520-
if (patch->immediate)
521-
return;
522-
523484
/*
524485
* Initialize all tasks to the initial patch state to prepare them for
525486
* switching to the target state.

samples/livepatch/livepatch-callbacks-demo.c

Lines changed: 0 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -197,21 +197,6 @@ static int livepatch_callbacks_demo_init(void)
197197
{
198198
int ret;
199199

200-
if (!klp_have_reliable_stack() && !patch.immediate) {
201-
/*
202-
* WARNING: Be very careful when using 'patch.immediate' in
203-
* your patches. It's ok to use it for simple patches like
204-
* this, but for more complex patches which change function
205-
* semantics, locking semantics, or data structures, it may not
206-
* be safe. Use of this option will also prevent removal of
207-
* the patch.
208-
*
209-
* See Documentation/livepatch/livepatch.txt for more details.
210-
*/
211-
patch.immediate = true;
212-
pr_notice("The consistency model isn't supported for your architecture. Bypassing safety mechanisms and applying the patch immediately.\n");
213-
}
214-
215200
ret = klp_register_patch(&patch);
216201
if (ret)
217202
return ret;

samples/livepatch/livepatch-sample.c

Lines changed: 0 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -71,21 +71,6 @@ static int livepatch_init(void)
7171
{
7272
int ret;
7373

74-
if (!klp_have_reliable_stack() && !patch.immediate) {
75-
/*
76-
* WARNING: Be very careful when using 'patch.immediate' in
77-
* your patches. It's ok to use it for simple patches like
78-
* this, but for more complex patches which change function
79-
* semantics, locking semantics, or data structures, it may not
80-
* be safe. Use of this option will also prevent removal of
81-
* the patch.
82-
*
83-
* See Documentation/livepatch/livepatch.txt for more details.
84-
*/
85-
patch.immediate = true;
86-
pr_notice("The consistency model isn't supported for your architecture. Bypassing safety mechanisms and applying the patch immediately.\n");
87-
}
88-
8974
ret = klp_register_patch(&patch);
9075
if (ret)
9176
return ret;

samples/livepatch/livepatch-shadow-fix1.c

Lines changed: 0 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -133,21 +133,6 @@ static int livepatch_shadow_fix1_init(void)
133133
{
134134
int ret;
135135

136-
if (!klp_have_reliable_stack() && !patch.immediate) {
137-
/*
138-
* WARNING: Be very careful when using 'patch.immediate' in
139-
* your patches. It's ok to use it for simple patches like
140-
* this, but for more complex patches which change function
141-
* semantics, locking semantics, or data structures, it may not
142-
* be safe. Use of this option will also prevent removal of
143-
* the patch.
144-
*
145-
* See Documentation/livepatch/livepatch.txt for more details.
146-
*/
147-
patch.immediate = true;
148-
pr_notice("The consistency model isn't supported for your architecture. Bypassing safety mechanisms and applying the patch immediately.\n");
149-
}
150-
151136
ret = klp_register_patch(&patch);
152137
if (ret)
153138
return ret;

0 commit comments

Comments
 (0)