Dusting the cobwebs off the consistency model again. This is based on
linux-next/master.
v1 was posted on 2015-02-09:
https://lkml.kernel.org/r/cover.1423499826.git.jpoimboe@redhat.com
v2 was posted on 2016-04-28:
https://lkml.kernel.org/r/cover.1461875890.git.jpoimboe@redhat.com
The biggest issue from v2 was finding a decent way to detect preemption
and page faults on the stack of a sleeping task. That problem was
solved by rewriting the x86 stack unwinder. The new unwinder helps
detect such cases by finding all pt_regs on the stack. When
preemption/page faults are detected, the stack is considered unreliable
and the patching of the task is deferred.
For more details about the consistency model, see patch 13/15.
---
v3:
- rebase on new x86 unwinder
- force !HAVE_RELIABLE_STACKTRACE arches to use patch->immediate for
now, because we don't have a way to transition kthreads otherwise
- rebase s390 TIF_PATCH_PENDING patch onto latest entry code
- update barrier comments and move barrier from the end of
klp_init_transition() to its callers
- "klp_work" -> "klp_transition_work"
- "klp_patch_task()" -> "klp_update_patch_state()"
- explicit _TIF_ALLWORK_MASK
- change klp_reverse_transition() to not try to complete transition.
instead modify the work queue delay to zero.
- get rid of klp_schedule_work() in favor of calling
schedule_delayed_work() directly with a KLP_TRANSITION_DELAY
- initialize klp_target_state to KLP_UNDEFINED
- move klp_target_state assignment to before patch->immediate check in
klp_init_transition()
- rcu_read_lock() in klp_update_patch_state(), test the thread flag in
patch task, synchronize_rcu() in klp_complete_transition()
- use kstrtobool() in enabled_store()
- change task_rq_lock() argument type to struct rq_flags
- add several WARN_ON_ONCE assertions for klp_target_state and
task->patch_state
v2:
- "universe" -> "patch state"
- rename klp_update_task_universe() -> klp_patch_task()
- add preempt IRQ tracking (TF_PREEMPT_IRQ)
- fix print_context_stack_reliable() bug
- improve print_context_stack_reliable() comments
- klp_ftrace_handler comment fixes
- add "patch_state" proc file to tid_base_stuff
- schedule work even for !RELIABLE_STACKTRACE
- forked child inherits patch state from parent
- add detailed comment to livepatch.h klp_func definition about the
klp_func patched/transition state transitions
- update exit_to_usermode_loop() comment
- clear all TIF_KLP_NEED_UPDATE flags in klp_complete_transition()
- remove unnecessary function externs
- add livepatch documentation, sysfs documentation, /proc documentation
- /proc/pid/patch_state: -1 means no patch is currently being applied/reverted
- "TIF_KLP_NEED_UPDATE" -> "TIF_PATCH_PENDING"
- support for s390 and powerpc-le
- don't assume stacks with dynamic ftrace trampolines are reliable
- add _TIF_ALLWORK_MASK info to commit log
v1.9:
- revive from the dead and rebased
- reliable stacks!
- add support for immediate consistency model
- add a ton of comments
- fix up memory barriers
- remove "allow patch modules to be removed" patch for now, it still
needs more discussion and thought - it can be done with something
- "proc/pid/universe" -> "proc/pid/patch_status"
- remove WARN_ON_ONCE from !func condition in ftrace handler -- can
happen because of RCU
- keep klp_mutex private by putting the work_fn in core.c
- convert states from int to boolean
- remove obsolete '@state' comments
- several header file and include improvements suggested by Jiri S
- change kallsyms_lookup_size_offset() errors from EINVAL -> ENOENT
- change proc file permissions S_IRUGO -> USR
- use klp_for_each_object/func helpers
---
Jiri Slaby (1):
livepatch/s390: reorganize TIF thread flag bits
Josh Poimboeuf (12):
stacktrace/x86: add function for detecting reliable stack traces
x86/entry: define _TIF_ALLWORK_MASK flags explicitly
livepatch: temporary stubs for klp_patch_pending() and
klp_update_patch_state()
livepatch/x86: add TIF_PATCH_PENDING thread flag
livepatch/powerpc: add TIF_PATCH_PENDING thread flag
livepatch: separate enabled and patched states
livepatch: remove unnecessary object loaded check
livepatch: move patching functions into patch.c
livepatch: use kstrtobool() in enabled_store()
livepatch: store function sizes
livepatch: change to a per-task consistency model
livepatch: add /proc/<pid>/patch_state
Miroslav Benes (2):
livepatch/s390: add TIF_PATCH_PENDING thread flag
livepatch: allow removal of a disabled patch
Documentation/ABI/testing/sysfs-kernel-livepatch | 8 +
Documentation/filesystems/proc.txt | 18 +
Documentation/livepatch/livepatch.txt | 156 ++++++--
arch/Kconfig | 6 +
arch/powerpc/include/asm/thread_info.h | 4 +-
arch/powerpc/kernel/signal.c | 4 +
arch/s390/include/asm/thread_info.h | 24 +-
arch/s390/kernel/entry.S | 31 +-
arch/x86/Kconfig | 1 +
arch/x86/entry/common.c | 9 +-
arch/x86/include/asm/thread_info.h | 11 +-
arch/x86/include/asm/unwind.h | 6 +
arch/x86/kernel/stacktrace.c | 59 ++-
arch/x86/kernel/unwind_frame.c | 1 +
fs/proc/base.c | 15 +
include/linux/init_task.h | 9 +
include/linux/livepatch.h | 66 ++-
include/linux/sched.h | 3 +
include/linux/stacktrace.h | 8 +-
kernel/fork.c | 3 +
kernel/livepatch/Makefile | 2 +-
kernel/livepatch/core.c | 446 +++++++++------------
kernel/livepatch/patch.c | 261 ++++++++++++
kernel/livepatch/patch.h | 33 ++
kernel/livepatch/transition.c | 487 +++++++++++++++++++++++
kernel/livepatch/transition.h | 14 +
kernel/sched/idle.c | 4 +
kernel/stacktrace.c | 12 +-
samples/livepatch/livepatch-sample.c | 8 +-
29 files changed, 1367 insertions(+), 342 deletions(-)
create mode 100644 kernel/livepatch/patch.c
create mode 100644 kernel/livepatch/patch.h
create mode 100644 kernel/livepatch/transition.c
create mode 100644 kernel/livepatch/transition.h
--
2.7.4
For live patching and possibly other use cases, a stack trace is only
useful if it can be assured that it's completely reliable. Add a new
save_stack_trace_tsk_reliable() function to achieve that.
Scenarios which indicate that a stack trace may be unreliable:
- running task
- interrupt stack
- preemption
- corrupted stack data
- stack grows the wrong way
- stack walk doesn't reach the bottom
- user didn't provide a large enough entries array
Also add CONFIG_HAVE_RELIABLE_STACKTRACE so arch-independent code can
determine at build time whether the function is implemented.
Signed-off-by: Josh Poimboeuf <redacted>
---
arch/Kconfig | 6 +++++
arch/x86/Kconfig | 1 +
arch/x86/include/asm/unwind.h | 6 +++++
arch/x86/kernel/stacktrace.c | 59 +++++++++++++++++++++++++++++++++++++++++-
arch/x86/kernel/unwind_frame.c | 1 +
include/linux/stacktrace.h | 8 +++---
kernel/stacktrace.c | 12 +++++++--
7 files changed, 87 insertions(+), 6 deletions(-)
Add the TIF_PATCH_PENDING thread flag to enable the new livepatch
per-task consistency model for powerpc. The bit getting set indicates
the thread has a pending patch which needs to be applied when the thread
exits the kernel.
The bit is included in the _TIF_USER_WORK_MASK macro so that
do_notify_resume() and klp_update_patch_state() get called when the bit
is set.
Signed-off-by: Josh Poimboeuf <redacted>
---
arch/powerpc/include/asm/thread_info.h | 4 +++-
arch/powerpc/kernel/signal.c | 4 ++++
2 files changed, 7 insertions(+), 1 deletion(-)
Add the TIF_PATCH_PENDING thread flag to enable the new livepatch
per-task consistency model for x86_64. The bit getting set indicates
the thread has a pending patch which needs to be applied when the thread
exits the kernel.
The bit is placed in the _TIF_ALLWORK_MASK macro, which results in
exit_to_usermode_loop() calling klp_update_patch_state() when it's set.
Signed-off-by: Josh Poimboeuf <redacted>
---
arch/x86/entry/common.c | 9 ++++++---
arch/x86/include/asm/thread_info.h | 4 +++-
2 files changed, 9 insertions(+), 4 deletions(-)
From: Miroslav Benes <mbenes@suse.cz>
Currently we do not allow patch module to unload since there is no
method to determine if a task is still running in the patched code.
The consistency model gives us the way because when the unpatching
finishes we know that all tasks were marked as safe to call an original
function. Thus every new call to the function calls the original code
and at the same time no task can be somewhere in the patched code,
because it had to leave that code to be marked as safe.
We can safely let the patch module go after that.
Completion is used for synchronization between module removal and sysfs
infrastructure in a similar way to commit 942e443127e9 ("module: Fix
mod->mkobj.kobj potentially freed too early").
Note that we still do not allow the removal for immediate model, that is
no consistency model. The module refcount may increase in this case if
somebody disables and enables the patch several times. This should not
cause any harm.
With this change a call to try_module_get() is moved to
__klp_enable_patch from klp_register_patch to make module reference
counting symmetric (module_put() is in a patch disable path) and to
allow to take a new reference to a disabled module when being enabled.
Also all kobject_put(&patch->kobj) calls are moved outside of klp_mutex
lock protection to prevent a deadlock situation when
klp_unregister_patch is called and sysfs directories are removed. There
is no need to do the same for other kobject_put() callsites as we
currently do not have their sysfs counterparts.
Signed-off-by: Miroslav Benes <mbenes@suse.cz>
Signed-off-by: Josh Poimboeuf <redacted>
---
Documentation/livepatch/livepatch.txt | 29 ++++---------
include/linux/livepatch.h | 3 ++
kernel/livepatch/core.c | 80 ++++++++++++++++++++++-------------
kernel/livepatch/transition.c | 12 +++++-
samples/livepatch/livepatch-sample.c | 1 -
5 files changed, 72 insertions(+), 53 deletions(-)
@@ -265,8 +265,15 @@ section "Livepatch life-cycle" below for more details about these two operations. Module removal is only safe when there are no users of the underlying-functions. The immediate consistency model is not able to detect this;-therefore livepatch modules cannot be removed. See "Limitations" below.+functions. The immediate consistency model is not able to detect this. The+code just redirects the functions at the very beginning and it does not+check if the functions are in use. In other words, it knows when the+functions get called but it does not know when the functions return.+Therefore it cannot be decided when the livepatch module can be safely+removed. This is solved by a hybrid consistency model. When the system is+transitioned to a new patch state (patched/unpatched) it is guaranteed that+no task sleeps or runs in the old code.+ 5. Livepatch life-cycle =======================
@@ -437,24 +444,6 @@ The current Livepatch implementation has several limitations: There is work in progress to remove this limitation.- + Livepatch modules can not be removed.-- The current implementation just redirects the functions at the very- beginning. It does not check if the functions are in use. In other- words, it knows when the functions get called but it does not- know when the functions return. Therefore it can not decide when- the livepatch module can be safely removed.-- This will get most likely solved once a more complex consistency model- is supported. The idea is that a safe state for patching should also- mean a safe state for removing the patch.-- Note that the patch itself might get disabled by writing zero- to /sys/kernel/livepatch/<patch>/enabled. It causes that the new- code will not longer get called. But it does not guarantee- that anyone is not sleeping anywhere in the new code.-- + Livepatch works reliably only when the dynamic ftrace is located at the very beginning of the function.
Expose the per-task patch state value so users can determine which tasks
are holding up completion of a patching operation.
Signed-off-by: Josh Poimboeuf <redacted>
---
Documentation/filesystems/proc.txt | 18 ++++++++++++++++++
fs/proc/base.c | 15 +++++++++++++++
2 files changed, 33 insertions(+)
@@ -44,6 +44,7 @@ Table of Contents 3.8 /proc/<pid>/fdinfo/<fd> - Information about opened file 3.9 /proc/<pid>/map_files - Information about memory mapped files 3.10 /proc/<pid>/timerslack_ns - Task timerslack value+ 3.11 /proc/<pid>/patch_state - Livepatch patch operation state 4 Configuring procfs 4.1 Mount options
@@ -1886,6 +1887,23 @@ Valid values are from 0 - ULLONG_MAX An application setting the value must have PTRACE_MODE_ATTACH_FSCREDS level permissions on the task specified to change its timerslack_ns value.+3.11 /proc/<pid>/patch_state - Livepatch patch operation state+-----------------------------------------------------------------+When CONFIG_LIVEPATCH is enabled, this file displays the value of the+patch state for the task.++A value of '-1' indicates that no patch is in transition.++A value of '0' indicates that a patch is in transition and the task is+unpatched. If the patch is being enabled, then the task hasn't been+patched yet. If the patch is being disabled, then the task has already+been unpatched.++A value of '1' indicates that a patch is in transition and the task is+patched. If the patch is being enabled, then the task has already been+patched. If the patch is being disabled, then the task hasn't been+unpatched yet.+ ------------------------------------------------------------------------------ Configuring procfs
@@ -314,171 +279,6 @@ static int klp_write_object_relocations(struct module *pmod,returnret;}-staticvoidnotraceklp_ftrace_handler(unsignedlongip,-unsignedlongparent_ip,-structftrace_ops*fops,-structpt_regs*regs)-{-structklp_ops*ops;-structklp_func*func;--ops=container_of(fops,structklp_ops,fops);--rcu_read_lock();-func=list_first_or_null_rcu(&ops->func_stack,structklp_func,-stack_node);-if(WARN_ON_ONCE(!func))-gotounlock;--klp_arch_set_pc(regs,(unsignedlong)func->new_func);-unlock:-rcu_read_unlock();-}--/*-*Convertafunctionaddressintotheappropriateftracelocation.-*-*Usuallythisisjusttheaddressofthefunction,butonsomearchitectures-*it'smorecomplicatedsoallowthemtoprovideacustombehaviour.-*/-#ifndef klp_get_ftrace_location-staticunsignedlongklp_get_ftrace_location(unsignedlongfaddr)-{-returnfaddr;-}-#endif--staticvoidklp_unpatch_func(structklp_func*func)-{-structklp_ops*ops;--if(WARN_ON(!func->patched))-return;-if(WARN_ON(!func->old_addr))-return;--ops=klp_find_ops(func->old_addr);-if(WARN_ON(!ops))-return;--if(list_is_singular(&ops->func_stack)){-unsignedlongftrace_loc;--ftrace_loc=klp_get_ftrace_location(func->old_addr);-if(WARN_ON(!ftrace_loc))-return;--WARN_ON(unregister_ftrace_function(&ops->fops));-WARN_ON(ftrace_set_filter_ip(&ops->fops,ftrace_loc,1,0));--list_del_rcu(&func->stack_node);-list_del(&ops->node);-kfree(ops);-}else{-list_del_rcu(&func->stack_node);-}--func->patched=false;-}--staticintklp_patch_func(structklp_func*func)-{-structklp_ops*ops;-intret;--if(WARN_ON(!func->old_addr))-return-EINVAL;--if(WARN_ON(func->patched))-return-EINVAL;--ops=klp_find_ops(func->old_addr);-if(!ops){-unsignedlongftrace_loc;--ftrace_loc=klp_get_ftrace_location(func->old_addr);-if(!ftrace_loc){-pr_err("failed to find location for function '%s'\n",-func->old_name);-return-EINVAL;-}--ops=kzalloc(sizeof(*ops),GFP_KERNEL);-if(!ops)-return-ENOMEM;--ops->fops.func=klp_ftrace_handler;-ops->fops.flags=FTRACE_OPS_FL_SAVE_REGS|-FTRACE_OPS_FL_DYNAMIC|-FTRACE_OPS_FL_IPMODIFY;--list_add(&ops->node,&klp_ops);--INIT_LIST_HEAD(&ops->func_stack);-list_add_rcu(&func->stack_node,&ops->func_stack);--ret=ftrace_set_filter_ip(&ops->fops,ftrace_loc,0,0);-if(ret){-pr_err("failed to set ftrace filter for function '%s' (%d)\n",-func->old_name,ret);-gotoerr;-}--ret=register_ftrace_function(&ops->fops);-if(ret){-pr_err("failed to register ftrace handler for function '%s' (%d)\n",-func->old_name,ret);-ftrace_set_filter_ip(&ops->fops,ftrace_loc,1,0);-gotoerr;-}---}else{-list_add_rcu(&func->stack_node,&ops->func_stack);-}--func->patched=true;--return0;--err:-list_del_rcu(&func->stack_node);-list_del(&ops->node);-kfree(ops);-returnret;-}--staticvoidklp_unpatch_object(structklp_object*obj)-{-structklp_func*func;--klp_for_each_func(obj,func)-if(func->patched)-klp_unpatch_func(func);--obj->patched=false;-}--staticintklp_patch_object(structklp_object*obj)-{-structklp_func*func;-intret;--if(WARN_ON(obj->patched))-return-EINVAL;--klp_for_each_func(obj,func){-ret=klp_patch_func(func);-if(ret){-klp_unpatch_object(obj);-returnret;-}-}-obj->patched=true;--return0;-}-staticint__klp_disable_patch(structklp_patch*patch){structklp_object*obj;
@@ -0,0 +1,213 @@+/*+*patch.c-livepatchpatchingfunctions+*+*Copyright(C)2014SethJennings<sjenning@redhat.com>+*Copyright(C)2014SUSE+*Copyright(C)2015JoshPoimboeuf<jpoimboe@redhat.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicense+*aspublishedbytheFreeSoftwareFoundation;eitherversion2+*oftheLicense,or(atyouroption)anylaterversion.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*+*YoushouldhavereceivedacopyoftheGNUGeneralPublicLicense+*alongwiththisprogram;ifnot,see<http://www.gnu.org/licenses/>.+*/++#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt++#include<linux/livepatch.h>+#include<linux/list.h>+#include<linux/ftrace.h>+#include<linux/rculist.h>+#include<linux/slab.h>+#include<linux/bug.h>+#include<linux/printk.h>+#include"patch.h"++staticLIST_HEAD(klp_ops);++structklp_ops*klp_find_ops(unsignedlongold_addr)+{+structklp_ops*ops;+structklp_func*func;++list_for_each_entry(ops,&klp_ops,node){+func=list_first_entry(&ops->func_stack,structklp_func,+stack_node);+if(func->old_addr==old_addr)+returnops;+}++returnNULL;+}++staticvoidnotraceklp_ftrace_handler(unsignedlongip,+unsignedlongparent_ip,+structftrace_ops*fops,+structpt_regs*regs)+{+structklp_ops*ops;+structklp_func*func;++ops=container_of(fops,structklp_ops,fops);++rcu_read_lock();+func=list_first_or_null_rcu(&ops->func_stack,structklp_func,+stack_node);+if(WARN_ON_ONCE(!func))+gotounlock;++klp_arch_set_pc(regs,(unsignedlong)func->new_func);+unlock:+rcu_read_unlock();+}++/*+*Convertafunctionaddressintotheappropriateftracelocation.+*+*Usuallythisisjusttheaddressofthefunction,butonsomearchitectures+*it'smorecomplicatedsoallowthemtoprovideacustombehaviour.+*/+#ifndef klp_get_ftrace_location+staticunsignedlongklp_get_ftrace_location(unsignedlongfaddr)+{+returnfaddr;+}+#endif++staticvoidklp_unpatch_func(structklp_func*func)+{+structklp_ops*ops;++if(WARN_ON(!func->patched))+return;+if(WARN_ON(!func->old_addr))+return;++ops=klp_find_ops(func->old_addr);+if(WARN_ON(!ops))+return;++if(list_is_singular(&ops->func_stack)){+unsignedlongftrace_loc;++ftrace_loc=klp_get_ftrace_location(func->old_addr);+if(WARN_ON(!ftrace_loc))+return;++WARN_ON(unregister_ftrace_function(&ops->fops));+WARN_ON(ftrace_set_filter_ip(&ops->fops,ftrace_loc,1,0));++list_del_rcu(&func->stack_node);+list_del(&ops->node);+kfree(ops);+}else{+list_del_rcu(&func->stack_node);+}++func->patched=false;+}++staticintklp_patch_func(structklp_func*func)+{+structklp_ops*ops;+intret;++if(WARN_ON(!func->old_addr))+return-EINVAL;++if(WARN_ON(func->patched))+return-EINVAL;++ops=klp_find_ops(func->old_addr);+if(!ops){+unsignedlongftrace_loc;++ftrace_loc=klp_get_ftrace_location(func->old_addr);+if(!ftrace_loc){+pr_err("failed to find location for function '%s'\n",+func->old_name);+return-EINVAL;+}++ops=kzalloc(sizeof(*ops),GFP_KERNEL);+if(!ops)+return-ENOMEM;++ops->fops.func=klp_ftrace_handler;+ops->fops.flags=FTRACE_OPS_FL_SAVE_REGS|+FTRACE_OPS_FL_DYNAMIC|+FTRACE_OPS_FL_IPMODIFY;++list_add(&ops->node,&klp_ops);++INIT_LIST_HEAD(&ops->func_stack);+list_add_rcu(&func->stack_node,&ops->func_stack);++ret=ftrace_set_filter_ip(&ops->fops,ftrace_loc,0,0);+if(ret){+pr_err("failed to set ftrace filter for function '%s' (%d)\n",+func->old_name,ret);+gotoerr;+}++ret=register_ftrace_function(&ops->fops);+if(ret){+pr_err("failed to register ftrace handler for function '%s' (%d)\n",+func->old_name,ret);+ftrace_set_filter_ip(&ops->fops,ftrace_loc,1,0);+gotoerr;+}+++}else{+list_add_rcu(&func->stack_node,&ops->func_stack);+}++func->patched=true;++return0;++err:+list_del_rcu(&func->stack_node);+list_del(&ops->node);+kfree(ops);+returnret;+}++voidklp_unpatch_object(structklp_object*obj)+{+structklp_func*func;++klp_for_each_func(obj,func)+if(func->patched)+klp_unpatch_func(func);++obj->patched=false;+}++intklp_patch_object(structklp_object*obj)+{+structklp_func*func;+intret;++if(WARN_ON(obj->patched))+return-EINVAL;++klp_for_each_func(obj,func){+ret=klp_patch_func(func);+if(ret){+klp_unpatch_object(obj);+returnret;+}+}+obj->patched=true;++return0;+}
Once we have a consistency model, patches and their objects will be
enabled and disabled at different times. For example, when a patch is
disabled, its loaded objects' funcs can remain registered with ftrace
indefinitely until the unpatching operation is complete and they're no
longer in use.
It's less confusing if we give them different names: patches can be
enabled or disabled; objects (and their funcs) can be patched or
unpatched:
- Enabled means that a patch is logically enabled (but not necessarily
fully applied).
- Patched means that an object's funcs are registered with ftrace and
added to the klp_ops func stack.
Also, since these states are binary, represent them with booleans
instead of ints.
Signed-off-by: Josh Poimboeuf <redacted>
---
include/linux/livepatch.h | 17 ++++-------
kernel/livepatch/core.c | 72 +++++++++++++++++++++++------------------------
2 files changed, 42 insertions(+), 47 deletions(-)
@@ -348,11 +348,11 @@ static unsigned long klp_get_ftrace_location(unsigned long faddr)}#endif-staticvoidklp_disable_func(structklp_func*func)+staticvoidklp_unpatch_func(structklp_func*func){structklp_ops*ops;-if(WARN_ON(func->state!=KLP_ENABLED))+if(WARN_ON(!func->patched))return;if(WARN_ON(!func->old_addr))return;
@@ -389,7 +389,7 @@ static int klp_enable_func(struct klp_func *func)if(WARN_ON(!func->old_addr))return-EINVAL;-if(WARN_ON(func->state!=KLP_DISABLED))+if(WARN_ON(func->patched))return-EINVAL;ops=klp_find_ops(func->old_addr);
@@ -437,7 +437,7 @@ static int klp_enable_func(struct klp_func *func)list_add_rcu(&func->stack_node,&ops->func_stack);}-func->state=KLP_ENABLED;+func->patched=true;return0;
@@ -448,36 +448,36 @@ static int klp_enable_func(struct klp_func *func)returnret;}-staticvoidklp_disable_object(structklp_object*obj)+staticvoidklp_unpatch_object(structklp_object*obj){structklp_func*func;klp_for_each_func(obj,func)-if(func->state==KLP_ENABLED)-klp_disable_func(func);+if(func->patched)+klp_unpatch_func(func);-obj->state=KLP_DISABLED;+obj->patched=false;}-staticintklp_enable_object(structklp_object*obj)+staticintklp_patch_object(structklp_object*obj){structklp_func*func;intret;-if(WARN_ON(obj->state!=KLP_DISABLED))+if(WARN_ON(obj->patched))return-EINVAL;if(WARN_ON(!klp_is_object_loaded(obj)))return-EINVAL;klp_for_each_func(obj,func){-ret=klp_enable_func(func);+ret=klp_patch_func(func);if(ret){-klp_disable_object(obj);+klp_unpatch_object(obj);returnret;}}-obj->state=KLP_ENABLED;+obj->patched=true;return0;}
@@ -488,17 +488,17 @@ static int __klp_disable_patch(struct klp_patch *patch)/* enforce stacking: only the last enabled patch can be disabled */if(!list_is_last(&patch->list,&klp_patches)&&-list_next_entry(patch,list)->state==KLP_ENABLED)+list_next_entry(patch,list)->enabled)return-EBUSY;pr_notice("disabling patch '%s'\n",patch->mod->name);klp_for_each_object(patch,obj){-if(obj->state==KLP_ENABLED)-klp_disable_object(obj);+if(obj->patched)+klp_unpatch_object(obj);}-patch->state=KLP_DISABLED;+patch->enabled=false;return0;}
@@ -522,7 +522,7 @@ int klp_disable_patch(struct klp_patch *patch)gotoerr;}-if(patch->state==KLP_DISABLED){+if(!patch->enabled){ret=-EINVAL;gotoerr;}
@@ -540,12 +540,12 @@ static int __klp_enable_patch(struct klp_patch *patch)structklp_object*obj;intret;-if(WARN_ON(patch->state!=KLP_DISABLED))+if(WARN_ON(patch->enabled))return-EINVAL;/* enforce stacking: only the first disabled patch can be enabled */if(patch->list.prev!=&klp_patches&&-list_prev_entry(patch,list)->state==KLP_DISABLED)+!list_prev_entry(patch,list)->enabled)return-EBUSY;pr_notice("enabling patch '%s'\n",patch->mod->name);
@@ -554,12 +554,12 @@ static int __klp_enable_patch(struct klp_patch *patch)if(!klp_is_object_loaded(obj))continue;-ret=klp_enable_object(obj);+ret=klp_patch_object(obj);if(ret)gotounregister;}-patch->state=KLP_ENABLED;+patch->enabled=true;return0;
@@ -617,20 +617,20 @@ static ssize_t enabled_store(struct kobject *kobj, struct kobj_attribute *attr,if(ret)return-EINVAL;-if(val!=KLP_DISABLED&&val!=KLP_ENABLED)+if(val>1)return-EINVAL;patch=container_of(kobj,structklp_patch,kobj);mutex_lock(&klp_mutex);-if(val==patch->state){+if(patch->enabled==val){/* already in requested state */ret=-EINVAL;gotoerr;}-if(val==KLP_ENABLED){+if(val){ret=__klp_enable_patch(patch);if(ret)gotoerr;
@@ -749,7 +749,7 @@ static int klp_init_func(struct klp_object *obj, struct klp_func *func)return-EINVAL;INIT_LIST_HEAD(&func->stack_node);-func->state=KLP_DISABLED;+func->patched=false;/* The format for the sysfs directory is <function,sympos> where sympos*isthenthoccurrenceofthissymbolinkallsymsforthepatched
For the consistency model we'll need to know the sizes of the old and
new functions to determine if they're on the stacks of any tasks.
Signed-off-by: Josh Poimboeuf <redacted>
---
include/linux/livepatch.h | 3 +++
kernel/livepatch/core.c | 16 ++++++++++++++++
2 files changed, 19 insertions(+)
From: Miroslav Benes <mbenes@suse.cz>
Update a task's patch state when returning from a system call or user
space interrupt, or after handling a signal.
This greatly increases the chances of a patch operation succeeding. If
a task is I/O bound, it can be patched when returning from a system
call. If a task is CPU bound, it can be patched when returning from an
interrupt. If a task is sleeping on a to-be-patched function, the user
can send SIGSTOP and SIGCONT to force it to switch.
Since there are two ways the syscall can be restarted on return from a
signal handling process, it is important to clear the flag before
do_signal() is called. Otherwise we could miss the migration if we used
SIGSTOP/SIGCONT procedure or fake signal to migrate patching blocking
tasks. If we place our hook to sysc_work label in entry before
TIF_SIGPENDING is evaluated we kill two birds with one stone. The task
is correctly migrated in all return paths from a syscall.
Signed-off-by: Miroslav Benes <mbenes@suse.cz>
Signed-off-by: Josh Poimboeuf <redacted>
---
arch/s390/include/asm/thread_info.h | 2 ++
arch/s390/kernel/entry.S | 31 ++++++++++++++++++++++++++++++-
2 files changed, 32 insertions(+), 1 deletion(-)
@@ -352,6 +352,11 @@ ENTRY(system_call)#endifTSTMSK__PT_FLAGS(%r11),_PIF_PER_TRAPjo.Lsysc_singlestep+#ifdef CONFIG_LIVEPATCH+TSTMSK__TI_flags(%r12),_TIF_PATCH_PENDING+jo.Lsysc_patch_pending# handle live patching just before+# signals and possible syscall restart+#endifTSTMSK__TI_flags(%r12),_TIF_SIGPENDINGjo.Lsysc_sigpendingTSTMSK__TI_flags(%r12),_TIF_NOTIFY_RESUME
@@ -426,6 +431,16 @@ ENTRY(system_call)#endif#+# _TIF_PATCH_PENDING is set, call klp_update_patch_state+#+#ifdef CONFIG_LIVEPATCH+.Lsysc_patch_pending:+lg%r2,__LC_CURRENT# pass pointer to task struct+larl%r14,.Lsysc_return+jgklp_update_patch_state+#endif++## _PIF_PER_TRAP is set, call do_per_trap#.Lsysc_singlestep:
The sysfs enabled value is a boolean, so kstrtobool() is a better fit
for parsing the input string since it does the range checking for us.
Suggested-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Josh Poimboeuf <redacted>
---
kernel/livepatch/core.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
klp_patch_object()'s callers already ensure that the object is loaded,
so its call to klp_is_object_loaded() is unnecessary.
This will also make it possible to move the patching code into a
separate file.
Signed-off-by: Josh Poimboeuf <redacted>
---
kernel/livepatch/core.c | 3 ---
1 file changed, 3 deletions(-)
The _TIF_ALLWORK_MASK macro automatically includes the least-significant
16 bits of the thread_info flags, which is less than obvious and tends
to create confusion and surprises when reading or modifying the code.
Define the flags explicitly.
Signed-off-by: Josh Poimboeuf <redacted>
---
arch/x86/include/asm/thread_info.h | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
@@ -73,9 +73,6 @@ struct thread_info {*threadinformationflags*-theseareprocessstateflagsthatvariousassemblyfiles*mayneedtoaccess-*-pendingwork-to-be-doneflagsareinLSW-*-otherflagsinMSW-*Warning:layoutofLSWishardcodedinentry.S*/#define TIF_SYSCALL_TRACE 0 /* syscall trace active */#define TIF_NOTIFY_RESUME 1 /* callback before returning to user */
@@ -133,8 +130,10 @@ struct thread_info {/* work to do on any return to user space */#define _TIF_ALLWORK_MASK \-((0x0000FFFF&~_TIF_SECCOMP)|_TIF_SYSCALL_TRACEPOINT|\-_TIF_NOHZ)+(_TIF_SYSCALL_TRACE|_TIF_NOTIFY_RESUME|_TIF_SIGPENDING|\+_TIF_SINGLESTEP|_TIF_NEED_RESCHED|_TIF_SYSCALL_EMU|\+_TIF_SYSCALL_AUDIT|_TIF_USER_RETURN_NOTIFY|_TIF_UPROBE|\+_TIF_SYSCALL_TRACEPOINT|_TIF_NOHZ)/* flags to check in __switch_to() */#define _TIF_WORK_CTXSW \
Create temporary stubs for klp_patch_pending() and
klp_update_patch_state() so we can add TIF_PATCH_PENDING to different
architectures in separate patches without breaking build bisectability.
Signed-off-by: Josh Poimboeuf <redacted>
---
include/linux/livepatch.h | 7 ++++++-
kernel/livepatch/core.c | 3 +++
2 files changed, 9 insertions(+), 1 deletion(-)
From: Jiri Slaby <redacted>
Group the TIF thread flag bits by their inclusion in the _TIF_WORK and
_TIF_TRACE macros.
Signed-off-by: Jiri Slaby <redacted>
Signed-off-by: Josh Poimboeuf <redacted>
---
arch/s390/include/asm/thread_info.h | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
Change livepatch to use a basic per-task consistency model. This is the
foundation which will eventually enable us to patch those ~10% of
security patches which change function or data semantics. This is the
biggest remaining piece needed to make livepatch more generally useful.
This code stems from the design proposal made by Vojtech [1] in November
2014. It's a hybrid of kGraft and kpatch: it uses kGraft's per-task
consistency and syscall barrier switching combined with kpatch's stack
trace switching. There are also a number of fallback options which make
it quite flexible.
Patches are applied on a per-task basis, when the task is deemed safe to
switch over. When a patch is enabled, livepatch enters into a
transition state where tasks are converging to the patched state.
Usually this transition state can complete in a few seconds. The same
sequence occurs when a patch is disabled, except the tasks converge from
the patched state to the unpatched state.
An interrupt handler inherits the patched state of the task it
interrupts. The same is true for forked tasks: the child inherits the
patched state of the parent.
Livepatch uses several complementary approaches to determine when it's
safe to patch tasks:
1. The first and most effective approach is stack checking of sleeping
tasks. If no affected functions are on the stack of a given task,
the task is patched. In most cases this will patch most or all of
the tasks on the first try. Otherwise it'll keep trying
periodically. This option is only available if the architecture has
reliable stacks (HAVE_RELIABLE_STACKTRACE).
2. The second approach, if needed, is kernel exit switching. A
task is switched when it returns to user space from a system call, a
user space IRQ, or a signal. It's useful in the following cases:
a) Patching I/O-bound user tasks which are sleeping on an affected
function. In this case you have to send SIGSTOP and SIGCONT to
force it to exit the kernel and be patched.
b) Patching CPU-bound user tasks. If the task is highly CPU-bound
then it will get patched the next time it gets interrupted by an
IRQ.
c) In the future it could be useful for applying patches for
architectures which don't yet have HAVE_RELIABLE_STACKTRACE. In
this case you would have to signal most of the tasks on the
system. However this isn't supported yet because there's
currently no way to patch kthreads without
HAVE_RELIABLE_STACKTRACE.
3. For idle "swapper" tasks, since they don't ever exit the kernel, they
instead have a klp_update_patch_state() call in the idle loop which
allows them to be patched before the CPU enters the idle state.
(Note there's not yet such an approach for kthreads.)
All the above approaches may be skipped by setting the 'immediate' flag
in the 'klp_patch' struct, which will disable per-task consistency and
patch all tasks immediately. This can be useful if the patch doesn't
change any function or data semantics. Note that, even with this flag
set, it's possible that some tasks may still be running with an old
version of the function, until that function returns.
There's also an 'immediate' flag in the 'klp_func' struct which allows
you to specify that certain functions in the patch can be applied
without per-task consistency. This might be useful if you want to patch
a common function like schedule(), and the function change doesn't need
consistency but the rest of the patch does.
For architectures which don't have HAVE_RELIABLE_STACKTRACE, the user
must set patch->immediate which causes all tasks to be patched
immediately. This option should be used with care, only when the patch
doesn't change any function or data semantics.
In the future, architectures which don't have HAVE_RELIABLE_STACKTRACE
may be allowed to use per-task consistency if we can come up with
another way to patch kthreads.
The /sys/kernel/livepatch/<patch>/transition file shows whether a patch
is in transition. Only a single patch (the topmost patch on the stack)
can be in transition at a given time. A patch can remain in transition
indefinitely, if any of the tasks are stuck in the initial patch state.
A transition can be reversed and effectively canceled by writing the
opposite value to the /sys/kernel/livepatch/<patch>/enabled file while
the transition is in progress. Then all the tasks will attempt to
converge back to the original patch state.
[1] https://lkml.kernel.org/r/20141107140458.GA21774@suse.cz
Signed-off-by: Josh Poimboeuf <redacted>
---
Documentation/ABI/testing/sysfs-kernel-livepatch | 8 +
Documentation/livepatch/livepatch.txt | 127 +++++-
include/linux/init_task.h | 9 +
include/linux/livepatch.h | 40 +-
include/linux/sched.h | 3 +
kernel/fork.c | 3 +
kernel/livepatch/Makefile | 2 +-
kernel/livepatch/core.c | 123 +++++-
kernel/livepatch/patch.c | 50 ++-
kernel/livepatch/patch.h | 1 +
kernel/livepatch/transition.c | 479 +++++++++++++++++++++++
kernel/livepatch/transition.h | 14 +
kernel/sched/idle.c | 4 +
samples/livepatch/livepatch-sample.c | 7 +
14 files changed, 827 insertions(+), 43 deletions(-)
create mode 100644 kernel/livepatch/transition.c
create mode 100644 kernel/livepatch/transition.h
@@ -25,6 +25,14 @@ Description: code is currently applied. Writing 0 will disable the patch while writing 1 will re-enable the patch.+What: /sys/kernel/livepatch/<patch>/transition+Date: May 2016+KernelVersion: 4.11.0+Contact: live-patching@vger.kernel.org+Description:+ An attribute which indicates whether the patch is currently in+ transition.+ What: /sys/kernel/livepatch/<patch>/<object> Date: Nov 2014 KernelVersion: 3.19.0
@@ -72,7 +72,8 @@ example, they add a NULL pointer or a boundary check, fix a race by adding a missing memory barrier, or add some locking around a critical section. Most of these changes are self contained and the function presents itself the same way to the rest of the system. In this case, the functions might-be updated independently one by one.+be updated independently one by one. (This can be done by setting the+'immediate' flag in the klp_patch struct.) But there are more complex fixes. For example, a patch might change ordering of locking in multiple functions at the same time. Or a patch
@@ -86,20 +87,96 @@ or no data are stored in the modified structures at the moment. The theory about how to apply functions a safe way is rather complex. The aim is to define a so-called consistency model. It attempts to define conditions when the new implementation could be used so that the system-stays consistent. The theory is not yet finished. See the discussion at-http://thread.gmane.org/gmane.linux.kernel/1823033/focus=1828189--The current consistency model is very simple. It guarantees that either-the old or the new function is called. But various functions get redirected-one by one without any synchronization.--In other words, the current implementation _never_ modifies the behavior-in the middle of the call. It is because it does _not_ rewrite the entire-function in the memory. Instead, the function gets redirected at the-very beginning. But this redirection is used immediately even when-some other functions from the same patch have not been redirected yet.--See also the section "Limitations" below.+stays consistent.++Livepatch has a consistency model which is a hybrid of kGraft and+kpatch: it uses kGraft's per-task consistency and syscall barrier+switching combined with kpatch's stack trace switching. There are also+a number of fallback options which make it quite flexible.++Patches are applied on a per-task basis, when the task is deemed safe to+switch over. When a patch is enabled, livepatch enters into a+transition state where tasks are converging to the patched state.+Usually this transition state can complete in a few seconds. The same+sequence occurs when a patch is disabled, except the tasks converge from+the patched state to the unpatched state.++An interrupt handler inherits the patched state of the task it+interrupts. The same is true for forked tasks: the child inherits the+patched state of the parent.++Livepatch uses several complementary approaches to determine when it's+safe to patch tasks:++1. The first and most effective approach is stack checking of sleeping+ tasks. If no affected functions are on the stack of a given task,+ the task is patched. In most cases this will patch most or all of+ the tasks on the first try. Otherwise it'll keep trying+ periodically. This option is only available if the architecture has+ reliable stacks (HAVE_RELIABLE_STACKTRACE).++2. The second approach, if needed, is kernel exit switching. A+ task is switched when it returns to user space from a system call, a+ user space IRQ, or a signal. It's useful in the following cases:++ a) Patching I/O-bound user tasks which are sleeping on an affected+ function. In this case you have to send SIGSTOP and SIGCONT to+ force it to exit the kernel and be patched.+ b) Patching CPU-bound user tasks. If the task is highly CPU-bound+ then it will get patched the next time it gets interrupted by an+ IRQ.+ c) In the future it could be useful for applying patches for+ architectures which don't yet have HAVE_RELIABLE_STACKTRACE. In+ this case you would have to signal most of the tasks on the+ system. However this isn't supported yet because there's+ currently no way to patch kthreads without+ HAVE_RELIABLE_STACKTRACE.++3. For idle "swapper" tasks, since they don't ever exit the kernel, they+ instead have a klp_update_patch_state() call in the idle loop which+ allows them to be patched before the CPU enters the idle state.++ (Note there's not yet such an approach for kthreads.)++All the above approaches may be skipped by setting the 'immediate' flag+in the 'klp_patch' struct, which will disable per-task consistency and+patch all tasks immediately. This can be useful if the patch doesn't+change any function or data semantics. Note that, even with this flag+set, it's possible that some tasks may still be running with an old+version of the function, until that function returns.++There's also an 'immediate' flag in the 'klp_func' struct which allows+you to specify that certain functions in the patch can be applied+without per-task consistency. This might be useful if you want to patch+a common function like schedule(), and the function change doesn't need+consistency but the rest of the patch does.++For architectures which don't have HAVE_RELIABLE_STACKTRACE, the user+must set patch->immediate which causes all tasks to be patched+immediately. This option should be used with care, only when the patch+doesn't change any function or data semantics.++In the future, architectures which don't have HAVE_RELIABLE_STACKTRACE+may be allowed to use per-task consistency if we can come up with+another way to patch kthreads.++The /sys/kernel/livepatch/<patch>/transition file shows whether a patch+is in transition. Only a single patch (the topmost patch on the stack)+can be in transition at a given time. A patch can remain in transition+indefinitely, if any of the tasks are stuck in the initial patch state.++A transition can be reversed and effectively canceled by writing the+opposite value to the /sys/kernel/livepatch/<patch>/enabled file while+the transition is in progress. Then all the tasks will attempt to+converge back to the original patch state.++There's also a /proc/<pid>/patch_state file which can be used to+determine which tasks are blocking completion of a patching operation.+If a patch is in transition, this file shows 0 to indicate the task is+unpatched and 1 to indicate it's patched. Otherwise, if no patch is in+transition, it shows -1. Any tasks which are blocking the transition+can be signaled with SIGSTOP and SIGCONT to force them to change their+patched state. 4. Livepatch module
@@ -134,7 +211,7 @@ Documentation/livepatch/module-elf-format.txt for more details. 4.2. Metadata-------------+------------- The patch is described by several structures that split the information into three levels:
@@ -239,9 +316,15 @@ Registered patches might be enabled either by calling klp_enable_patch() or by writing '1' to /sys/kernel/livepatch/<name>/enabled. The system will start using the new implementation of the patched functions at this stage.-In particular, if an original function is patched for the first time, a-function specific struct klp_ops is created and an universal ftrace handler-is registered.+When a patch is enabled, livepatch enters into a transition state where+tasks are converging to the patched state. This is indicated by a value+of '1' in /sys/kernel/livepatch/<name>/transition. Once all tasks have+been patched, the 'transition' value changes to '0'. For more+information about this process, see the "Consistency model" section.++If an original function is patched for the first time, a function+specific struct klp_ops is created and an universal ftrace handler is+registered. Functions might be patched multiple times. The ftrace handler is registered only once for the given function. Further patches just add an entry to the
@@ -261,6 +344,12 @@ by writing '0' to /sys/kernel/livepatch/<name>/enabled. At this stage either the code from the previously enabled patch or even the original code gets used.+When a patch is disabled, livepatch enters into a transition state where+tasks are converging to the unpatched state. This is indicated by a+value of '1' in /sys/kernel/livepatch/<name>/transition. Once all tasks+have been unpatched, the 'transition' value changes to '0'. For more+information about this process, see the "Consistency model" section.+ Here all the functions (struct klp_func) associated with the to-be-disabled patch are removed from the corresponding struct klp_ops. The ftrace handler is unregistered and the struct klp_ops is freed when the func_stack list
@@ -1988,6 +1988,9 @@ struct task_struct {/* A live task holds one reference. */atomic_tstack_refcount;#endif+#ifdef CONFIG_LIVEPATCH+intpatch_state;+#endif/* CPU-specific state of this task */structthread_structthread;/*
@@ -85,7 +106,6 @@ static void klp_find_object_module(struct klp_object *obj)mutex_unlock(&module_mutex);}-/* klp_mutex must be held by caller */staticboolklp_is_patch_registered(structklp_patch*patch){structklp_patch*mypatch;
@@ -281,19 +301,28 @@ static int klp_write_object_relocations(struct module *pmod,staticint__klp_disable_patch(structklp_patch*patch){-structklp_object*obj;+if(klp_transition_patch)+return-EBUSY;/* enforce stacking: only the last enabled patch can be disabled */if(!list_is_last(&patch->list,&klp_patches)&&list_next_entry(patch,list)->enabled)return-EBUSY;-pr_notice("disabling patch '%s'\n",patch->mod->name);+klp_init_transition(patch,KLP_UNPATCHED);-klp_for_each_object(patch,obj){-if(obj->patched)-klp_unpatch_object(obj);-}+/*+*Enforcetheorderoftheklp_target_statewritein+*klp_init_transition()andtheTIF_PATCH_PENDINGwritesin+*klp_start_transition()toensurethatklp_update_patch_state()+*doesn'tsetatask->patch_statetoKLP_UNDEFINED.+*/+smp_wmb();++klp_start_transition();+if(!klp_try_complete_transition())+schedule_delayed_work(&klp_transition_work,+KLP_TRANSITION_DELAY);patch->enabled=false;
@@ -337,6 +366,9 @@ static int __klp_enable_patch(struct klp_patch *patch)structklp_object*obj;intret;+if(klp_transition_patch)+return-EBUSY;+if(WARN_ON(patch->enabled))return-EINVAL;
@@ -347,22 +379,42 @@ static int __klp_enable_patch(struct klp_patch *patch)pr_notice("enabling patch '%s'\n",patch->mod->name);+klp_init_transition(patch,KLP_PATCHED);++/*+*Enforcetheorderofthefunc->transitionwritesin+*klp_init_transition()andtheops->func_stackwritesin+*klp_patch_object(),sothatklp_ftrace_handler()willseethe+*func->transitionupdatesbeforethehandlerisregisteredandthe+*newfuncsbecomevisibletothehandler.+*/+smp_wmb();+klp_for_each_object(patch,obj){if(!klp_is_object_loaded(obj))continue;ret=klp_patch_object(obj);-if(ret)-gotounregister;+if(ret){+pr_warn("failed to enable patch '%s'\n",+patch->mod->name);++klp_unpatch_objects(patch);+klp_complete_transition();++returnret;+}}+klp_start_transition();++if(!klp_try_complete_transition())+schedule_delayed_work(&klp_transition_work,+KLP_TRANSITION_DELAY);+patch->enabled=true;return0;--unregister:-WARN_ON(__klp_disable_patch(patch));-returnret;}/**
@@ -544,6 +612,7 @@ static int klp_init_func(struct klp_object *obj, struct klp_func *func)INIT_LIST_HEAD(&func->stack_node);func->patched=false;+func->transition=false;/* The format for the sysfs directory is <function,sympos> where sympos*isthenthoccurrenceofthissymbolinkallsymsforthepatched
@@ -740,6 +809,14 @@ int klp_register_patch(struct klp_patch *patch)return-ENODEV;/*+*Architectureswithoutreliablestacktraceshavetoset+*patch->immediatebecausethere'scurrentlynowaytopatchkthreads+*withtheconsistencymodel.+*/+if(!klp_have_reliable_stack()&&!patch->immediate)+return-ENOSYS;++/**Areferenceistakenonthepatchmoduletopreventitfrombeing*unloaded.Rightnow,wedon'tallowpatchmodulestounloadsince*thereiscurrentlynomethodtodetermineifathreadisstill
@@ -788,7 +865,11 @@ int klp_module_coming(struct module *mod)gotoerr;}-if(!patch->enabled)+/*+*Onlypatchthemoduleifthepatchisenabledoris+*intransition.+*/+if(!patch->enabled&&patch!=klp_transition_patch)break;pr_notice("applying patch '%s' to loading module '%s'\n",
@@ -0,0 +1,479 @@+/*+*transition.c-KernelLivePatchingtransitionfunctions+*+*Copyright(C)2015-2016JoshPoimboeuf<jpoimboe@redhat.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicense+*aspublishedbytheFreeSoftwareFoundation;eitherversion2+*oftheLicense,or(atyouroption)anylaterversion.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*+*YoushouldhavereceivedacopyoftheGNUGeneralPublicLicense+*alongwiththisprogram;ifnot,see<http://www.gnu.org/licenses/>.+*/++#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt++#include<linux/cpu.h>+#include<linux/stacktrace.h>+#include"patch.h"+#include"transition.h"+#include"../sched/sched.h"++#define MAX_STACK_ENTRIES 100++structklp_patch*klp_transition_patch;++staticintklp_target_state=KLP_UNDEFINED;++/* called from copy_process() during fork */+voidklp_copy_process(structtask_struct*child)+{+child->patch_state=current->patch_state;++/* TIF_PATCH_PENDING gets copied in setup_thread_stack() */+}++/*+*klp_update_patch_state()-changethepatchedstateofatask+*@task:Thetasktochange+*+*Switchesthepatchedstateofthetasktothesetoffunctionsinthetarget+*patchstate.+*/+voidklp_update_patch_state(structtask_struct*task)+{+/*+*Thesynchronize_rcu()callinklp_try_complete_transition()ensures+*thiscriticalsectioncompletesbeforetheglobalpatchtransition+*isconsideredcompletesowedon'thavespuriouspatch_stateupdates+*afterwards.+*/+rcu_read_lock();++/*+*Thistest_and_clear_tsk_thread_flag()callalsoservesasaread+*barriertoenforcetheorderoftheTIF_PATCH_PENDINGand+*klp_target_statereads.Thecorrespondingwritebarriersarein+*__klp_disable_patch()andklp_reverse_transition().+*/+if(test_and_clear_tsk_thread_flag(task,TIF_PATCH_PENDING))+task->patch_state=READ_ONCE(klp_target_state);++rcu_read_unlock();+}++/*+*Initializetheglobaltargetpatchstateandalltaskstotheinitialpatch+*state,andinitializeallfunctiontransitionstatestotrueinpreparation+*forpatchingorunpatching.+*/+voidklp_init_transition(structklp_patch*patch,intstate)+{+structtask_struct*g,*task;+unsignedintcpu;+structklp_object*obj;+structklp_func*func;+intinitial_state=!state;++WARN_ON_ONCE(klp_target_state!=KLP_UNDEFINED);++klp_transition_patch=patch;++/*+*Settheglobaltargetpatchstatewhichtaskswillswitchto.This+*hasnoeffectuntiltheTIF_PATCH_PENDINGflagsgetsetlater.+*/+klp_target_state=state;++/*+*Ifthepatchcanbeappliedorrevertedimmediately,skipthe+*per-tasktransitions.+*/+if(patch->immediate)+return;++/*+*Initializealltaskstotheinitialpatchstatetopreparethemfor+*switchingtothetargetstate.+*/+read_lock(&tasklist_lock);+for_each_process_thread(g,task){+WARN_ON_ONCE(task->patch_state!=KLP_UNDEFINED);+task->patch_state=initial_state;+}+read_unlock(&tasklist_lock);++/*+*Dittofortheidle"swapper"tasks.+*/+get_online_cpus();+for_each_online_cpu(cpu){+task=idle_task(cpu);+WARN_ON_ONCE(task->patch_state!=KLP_UNDEFINED);+task->patch_state=initial_state;+}+put_online_cpus();++/*+*Enforcetheorderofthetask->patch_stateinitializationsandthe+*func->transitionupdatestoensurethat,intheenablepath,+*klp_ftrace_handler()doesn'tseeafuncintransitionwitha+*task->patch_stateofKLP_UNDEFINED.+*/+smp_wmb();++/*+*Setthefunctransitionstatessoklp_ftrace_handler()willknowto+*switchtothetransitionlogic.+*+*Whenpatching,thefuncsaren'tyetinthefunc_stackandwillbe+*madevisibletotheftracehandlershortlybythecallsto+*klp_patch_object().+*+*Whenunpatching,thefuncsarealreadyinthefunc_stackandsoare+*alreadyvisibletotheftracehandler.+*/+klp_for_each_object(patch,obj)+klp_for_each_func(obj,func)+func->transition=true;+}++/*+*Startthetransitiontothespecifiedtargetpatchstatesotaskscanbegin+*switchingtoit.+*/+voidklp_start_transition(void)+{+structtask_struct*g,*task;+unsignedintcpu;++WARN_ON_ONCE(klp_target_state==KLP_UNDEFINED);++pr_notice("'%s': %s...\n",klp_transition_patch->mod->name,+klp_target_state==KLP_PATCHED?"patching":"unpatching");++/*+*Ifthepatchcanbeappliedorrevertedimmediately,skipthe+*per-tasktransitions.+*/+if(klp_transition_patch->immediate)+return;++/*+*Markallnormaltasksasneedingapatchstateupdate.Astheypass+*throughthesyscallbarrierthey'llswitchovertothetargetstate+*(unlessweswitchtheminklp_try_complete_transition()first).+*/+read_lock(&tasklist_lock);+for_each_process_thread(g,task)+set_tsk_thread_flag(task,TIF_PATCH_PENDING);+read_unlock(&tasklist_lock);++/*+*Dittofortheidle"swapper"tasks,thoughtheynevercrossthe+*syscallbarrier.Insteadtheyswitchoverincpu_idle_loop().+*/+get_online_cpus();+for_each_online_cpu(cpu)+set_tsk_thread_flag(idle_task(cpu),TIF_PATCH_PENDING);+put_online_cpus();+}++/*+*Thetransitiontothetargetpatchstateiscomplete.Cleanupthedata+*structures.+*/+voidklp_complete_transition(void)+{+structklp_object*obj;+structklp_func*func;+structtask_struct*g,*task;+unsignedintcpu;++if(klp_transition_patch->immediate)+gotodone;++klp_for_each_object(klp_transition_patch,obj)+klp_for_each_func(obj,func)+func->transition=false;++read_lock(&tasklist_lock);+for_each_process_thread(g,task){+clear_tsk_thread_flag(task,TIF_PATCH_PENDING);+task->patch_state=KLP_UNDEFINED;+}+read_unlock(&tasklist_lock);++get_online_cpus();+for_each_online_cpu(cpu){+task=idle_task(cpu);+clear_tsk_thread_flag(task,TIF_PATCH_PENDING);+task->patch_state=KLP_UNDEFINED;+}+put_online_cpus();++done:+klp_target_state=KLP_UNDEFINED;+klp_transition_patch=NULL;+}++/*+*Determinewhetherthegivenstacktraceincludesanyreferencestoa+*to-be-patchedorto-be-unpatchedfunction.+*/+staticintklp_check_stack_func(structklp_func*func,+structstack_trace*trace)+{+unsignedlongfunc_addr,func_size,address;+structklp_ops*ops;+inti;++if(func->immediate)+return0;++for(i=0;i<trace->nr_entries;i++){+address=trace->entries[i];++if(klp_target_state==KLP_UNPATCHED){+/*+*Checkfortheto-be-unpatchedfunction+*(thefuncitself).+*/+func_addr=(unsignedlong)func->new_func;+func_size=func->new_size;+}else{+/*+*Checkfortheto-be-patchedfunction+*(thepreviousfunc).+*/+ops=klp_find_ops(func->old_addr);++if(list_is_singular(&ops->func_stack)){+/* original function */+func_addr=func->old_addr;+func_size=func->old_size;+}else{+/* previously patched function */+structklp_func*prev;++prev=list_next_entry(func,stack_node);+func_addr=(unsignedlong)prev->new_func;+func_size=prev->new_size;+}+}++if(address>=func_addr&&address<func_addr+func_size)+return-EAGAIN;+}++return0;+}++/*+*Determinewhetherit'ssafetotransitionthetasktothetargetpatchstate+*bylookingforanyto-be-patchedorto-be-unpatchedfunctionsonitsstack.+*/+staticintklp_check_stack(structtask_struct*task)+{+staticunsignedlongentries[MAX_STACK_ENTRIES];+structstack_tracetrace;+structklp_object*obj;+structklp_func*func;+intret;++trace.skip=0;+trace.nr_entries=0;+trace.max_entries=MAX_STACK_ENTRIES;+trace.entries=entries;+ret=save_stack_trace_tsk_reliable(task,&trace);+WARN_ON_ONCE(ret==-ENOSYS);+if(ret){+pr_debug("%s: %s:%d has an unreliable stack\n",+__func__,task->comm,task->pid);+returnret;+}++klp_for_each_object(klp_transition_patch,obj){+if(!obj->patched)+continue;+klp_for_each_func(obj,func){+ret=klp_check_stack_func(func,&trace);+if(ret){+pr_debug("%s: %s:%d is sleeping on function %s\n",+__func__,task->comm,task->pid,+func->old_name);+returnret;+}+}+}++return0;+}++/*+*Trytosafelyswitchatasktothetargetpatchstate.Ifit'scurrently+*running,orit'ssleepingonato-be-patchedorto-be-unpatchedfunction,or+*ifthestackisunreliable,returnfalse.+*/+staticboolklp_try_switch_task(structtask_struct*task)+{+structrq*rq;+structrq_flagsflags;+intret;+boolsuccess=false;++/* check if this task has already switched over */+if(task->patch_state==klp_target_state)+returntrue;++/*+*Forarcheswhichdon'thavereliablestacktraces,wehavetorely+*onothermethods(e.g.,switchingtasksatthesyscallbarrier).+*/+if(!klp_have_reliable_stack())+returnfalse;++/*+*Nowtrytocheckthestackforanyto-be-patchedorto-be-unpatched+*functions.Ifallgoeswell,switchthetasktothetargetpatch+*state.+*/+rq=task_rq_lock(task,&flags);++if(task_running(rq,task)&&task!=current){+pr_debug("%s: %s:%d is running\n",__func__,task->comm,+task->pid);+gotodone;+}++ret=klp_check_stack(task);+if(ret)+gotodone;++success=true;++clear_tsk_thread_flag(task,TIF_PATCH_PENDING);+task->patch_state=klp_target_state;++done:+task_rq_unlock(rq,task,&flags);+returnsuccess;+}++/*+*Trytoswitchallremainingtaskstothetargetpatchstatebywalkingthe+*stacksofsleepingtasksandlookingforanyto-be-patchedor+*to-be-unpatchedfunctions.Ifsuchfunctionsarefound,thetaskcan'tbe+*switchedyet.+*+*Ifanytasksarestillstuckintheinitialpatchstate,schedulearetry.+*/+boolklp_try_complete_transition(void)+{+unsignedintcpu;+structtask_struct*g,*task;+boolcomplete=true;++WARN_ON_ONCE(klp_target_state==KLP_UNDEFINED);++/*+*Ifthepatchcanbeappliedorrevertedimmediately,skipthe+*per-tasktransitions.+*/+if(klp_transition_patch->immediate)+gotosuccess;++/*+*Trytoswitchthetaskstothetargetpatchstatebywalkingtheir+*stacksandlookingforanyto-be-patchedorto-be-unpatched+*functions.Ifsuchfunctionsarefoundonastack,orifthestack+*isdeemedunreliable,thetaskcan'tbeswitchedyet.+*+*Usuallythiswilltransitionmost(orall)ofthetasksonasystem+*unlessthepatchincludeschangestoaverycommonfunction.+*/+read_lock(&tasklist_lock);+for_each_process_thread(g,task)+if(!klp_try_switch_task(task))+complete=false;+read_unlock(&tasklist_lock);++/*+*Dittofortheidle"swapper"tasks.+*/+get_online_cpus();+for_each_online_cpu(cpu)+if(!klp_try_switch_task(idle_task(cpu)))+complete=false;+put_online_cpus();++/*+*Sometasksweren'tabletobeswitchedover.Tryagainlaterand/or+*waitforothermethodslikesyscallbarrierswitching.+*/+if(!complete)+returnfalse;++success:++/*+*Whenunpatching,alltaskshavetransitionedtoKLP_UNPATCHEDsowe+*cannowremovethenewfunctionsfromthefunc_stack.+*/+if(klp_target_state==KLP_UNPATCHED)+klp_unpatch_objects(klp_transition_patch);++/*+*WaitforallRCUread-sidecriticalsectionstocomplete.+*+*Thishastwopurposes:+*+*1)Ensureallexistingcriticalsectionsinklp_update_patch_state()+*complete,sotask->patch_statewon'tbeunexpectedlyupdated+*later.+*+*2)Whenunpatching,don'tallowanyexistinginstancesof+*klp_ftrace_handler()toaccessanyobsoletefuncsbeforewereset+*thefunctransitionstatestofalse.Otherwisethehandlermay+*seethedeleted"new"func,seethatit'snotintransition,and+*wronglypickthenewversionofthefunction.+*/+synchronize_rcu();++pr_notice("'%s': %s complete\n",klp_transition_patch->mod->name,+klp_target_state==KLP_PATCHED?"patching":"unpatching");++/* we're done, now cleanup the data structures */+klp_complete_transition();++returntrue;+}++/*+*Thisfunctioncanbecalledinthemiddleofanexistingtransitionto+*reversethedirectionofthetargetpatchstate.Thiscanbedoneto+*effectivelycancelanexistingenableordisableoperationifthereareany+*taskswhicharestuckintheinitialpatchstate.+*/+voidklp_reverse_transition(void)+{+klp_transition_patch->enabled=!klp_transition_patch->enabled;++klp_target_state=!klp_target_state;++/*+*Enforcetheorderofthewritetoklp_target_stateaboveandthe+*TIF_PATCH_PENDINGwritesinklp_start_transition()toensurethat+*klp_update_patch_state()doesn'tsetawrongtask->patch_state.+*/+smp_wmb();++klp_start_transition();+}+
From: Andy Lutomirski <luto@amacapital.net> Date: 2016-12-08 18:28:04
On Thu, Dec 8, 2016 at 10:08 AM, Josh Poimboeuf [off-list ref] wrote:
Add the TIF_PATCH_PENDING thread flag to enable the new livepatch
per-task consistency model for x86_64. The bit getting set indicates
the thread has a pending patch which needs to be applied when the thread
exits the kernel.
The bit is placed in the _TIF_ALLWORK_MASK macro, which results in
exit_to_usermode_loop() calling klp_update_patch_state() when it's set.
Signed-off-by: Josh Poimboeuf <redacted>
Could you please elaborate on this? Preemption of a sleeping task and
faults as in the future (time) preemption and faults?
The normal way for a task to go to sleep is to call schedule(). objtool
ensures the stack trace is reliable in that case, by making sure that
all functions save the frame pointer on the stack before calling out to
another function.
But a task can also go to sleep in a few other ways. One way is by
preemption, where an interrupt handler interrupts the task and calls
preempt_schedule_irq(). Another way is by a page fault exception. In
both cases, there's no guarantee that the interrupted function saved the
frame pointer on the stack beforehand. So the stack trace might be
unreliable. Fortunately, interrupts and exceptions leave evidence
behind on the stack. So when walking the stack of a sleeping task, we
can detect when an IRQ or exception occurred, and consider such a stack
unreliable.
--
Josh
Could you please elaborate on this? Preemption of a sleeping task and
faults as in the future (time) preemption and faults?
The normal way for a task to go to sleep is to call schedule(). objtool
ensures the stack trace is reliable in that case, by making sure that
all functions save the frame pointer on the stack before calling out to
another function.
But a task can also go to sleep in a few other ways. One way is by
preemption, where an interrupt handler interrupts the task and calls
preempt_schedule_irq().
It's preempted, not sleeping. It's on_rq but not on_cpu.
Another way is by a page fault exception. In
both cases, there's no guarantee that the interrupted function saved the
frame pointer on the stack beforehand. So the stack trace might be
unreliable. Fortunately, interrupts and exceptions leave evidence
behind on the stack. So when walking the stack of a sleeping task, we
can detect when an IRQ or exception occurred, and consider such a stack
unreliable.
Thanks for the explanation. I presume a whole lot of this is arch specific
code? I'll look at the patches as well
Balbir
Could you please elaborate on this? Preemption of a sleeping task and
faults as in the future (time) preemption and faults?
The normal way for a task to go to sleep is to call schedule(). objtool
ensures the stack trace is reliable in that case, by making sure that
all functions save the frame pointer on the stack before calling out to
another function.
But a task can also go to sleep in a few other ways. One way is by
preemption, where an interrupt handler interrupts the task and calls
preempt_schedule_irq().
It's preempted, not sleeping. It's on_rq but not on_cpu.
You're right, I used the word "sleeping" when I meant "not currently
executing on a CPU". (Peter Z also pointed that out.)
Another way is by a page fault exception. In
quoted
both cases, there's no guarantee that the interrupted function saved the
frame pointer on the stack beforehand. So the stack trace might be
unreliable. Fortunately, interrupts and exceptions leave evidence
behind on the stack. So when walking the stack of a sleeping task, we
can detect when an IRQ or exception occurred, and consider such a stack
unreliable.
Thanks for the explanation. I presume a whole lot of this is arch specific
code? I'll look at the patches as well
Most of the new livepatch code is arch-independent, but the consistency
model part of it (i.e., !klp_patch.immediate) is currently only
supported by x86_64.
For adding support for other architectures, there are a few options:
1) Add CONFIG_HAVE_RELIABLE_STACKTRACE. This means porting objtool, and
for non-DWARF unwinders, also making sure there's a way for the stack
tracing code to detect interrupts on the stack.
2) Alternatively, figure out a way to patch kthreads without stack
checking. If all kthreads sleep in the same place, then we can
designate that place as a patching point. I think Petr M has been
working on that? In that case, arches without
HAVE_RELIABLE_STACKTRACE would still be able to use the
non-stack-checking parts of the consistency model:
a) patching user tasks when they cross the kernel/user space
boundary; and
b) patching kthreads and idle tasks at their designated patch points.
This option isn't as good as option 1 because it requires signaling
most of the tasks to patch them. But it could still be a good backup
option for those architectures which don't have reliable stack traces
yet.
In the meantime, other architectures can keep today's behavior by
setting klp_patch.immediate to true.
--
Josh
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-16 13:08:13
On Thu 2016-12-08 12:08:26, Josh Poimboeuf wrote:
For live patching and possibly other use cases, a stack trace is only
useful if it can be assured that it's completely reliable. Add a new
save_stack_trace_tsk_reliable() function to achieve that.
Scenarios which indicate that a stack trace may be unreliable:
- running task
It seems that this has to be enforced by save_stack_trace_tsk_reliable()
caller. It should be mentioned in the function description.
- interrupt stack
I guess that it is detected by saved regs on the stack. And it covers
also dynamic changes like kprobes. Do I get it correctly, please?
What about ftrace? Is ftrace without regs safe and detected?
- preemption
I wonder if some very active kthreads might almost always be
preempted using irq in preemptive kernel. Then they block
the conversion with the non-reliable stacks. Have you noticed
such problems, please?
- corrupted stack data
- stack grows the wrong way
This is detected in unwind_next_frame() and passed via state->error.
Am I right?
quoted hunk
- stack walk doesn't reach the bottom
- user didn't provide a large enough entries array
Also add CONFIG_HAVE_RELIABLE_STACKTRACE so arch-independent code can
determine at build time whether the function is implemented.
By other words, it we find regs on the stack, it almost always mean
a non-reliable stack. The only exception is when we are in the
userspace mode. Do I get it correctly, please?
+
+ /*
+ * This frame contains the (user mode) pt_regs at the
+ * end of the stack. Finish the unwind.
+ */
+ unwind_next_frame(&state);
+ break;
+ }
+
+ addr = unwind_get_return_address(&state);
+ if (!addr || save_stack_address(trace, addr, false))
+ return -1;
+ }
+
+ if (!unwind_done(&state) || unwind_error(&state))
+ return -1;
+
+ if (trace->nr_entries < trace->max_entries)
+ trace->entries[trace->nr_entries++] = ULONG_MAX;
+
+ return 0;
+}
Great work! I am surprised that it looks so straightforward.
I still have to think and investigate it more. But it looks
very promissing.
Best Regards,
Petr
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-16 14:18:39
On Thu 2016-12-08 12:08:27, Josh Poimboeuf wrote:
quoted hunk
The _TIF_ALLWORK_MASK macro automatically includes the least-significant
16 bits of the thread_info flags, which is less than obvious and tends
to create confusion and surprises when reading or modifying the code.
Define the flags explicitly.
Signed-off-by: Josh Poimboeuf <redacted>
---
arch/x86/include/asm/thread_info.h | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
Yup, this is not true because also some flags from the most
significant bits are in the _TIF_ALLWORK_MASK.
quoted hunk
- * - other flags in MSW
- * Warning: layout of LSW is hardcoded in entry.S
*/
#define TIF_SYSCALL_TRACE 0 /* syscall trace active */
#define TIF_NOTIFY_RESUME 1 /* callback before returning to user */
@@ -133,8 +130,10 @@ struct thread_info { /* work to do on any return to user space */ #define _TIF_ALLWORK_MASK \- ((0x0000FFFF & ~_TIF_SECCOMP) | _TIF_SYSCALL_TRACEPOINT | \- _TIF_NOHZ)+ (_TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME | _TIF_SIGPENDING | \+ _TIF_SINGLESTEP | _TIF_NEED_RESCHED | _TIF_SYSCALL_EMU | \+ _TIF_SYSCALL_AUDIT | _TIF_USER_RETURN_NOTIFY | _TIF_UPROBE | \+ _TIF_SYSCALL_TRACEPOINT | _TIF_NOHZ)
All flags are sorted by the number except for
_TIF_SINGLESTEP and _TIF_NEED_RESCHED ;-)
The patch does not change the existing behavior. The same
existing flags are listed.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-16 14:42:11
On Thu 2016-12-08 12:08:28, Josh Poimboeuf wrote:
quoted hunk
Create temporary stubs for klp_patch_pending() and
klp_update_patch_state() so we can add TIF_PATCH_PENDING to different
architectures in separate patches without breaking build bisectability.
Signed-off-by: Josh Poimboeuf <redacted>
---
include/linux/livepatch.h | 7 ++++++-
kernel/livepatch/core.c | 3 +++
2 files changed, 9 insertions(+), 1 deletion(-)
It seems that the stub for this function is enough.
Well, the extra function is just a cosmetic problem. If it could be
fixed, it would be great. But the patch makes sense:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-16 15:40:18
On Thu 2016-12-08 12:08:29, Josh Poimboeuf wrote:
Add the TIF_PATCH_PENDING thread flag to enable the new livepatch
per-task consistency model for x86_64. The bit getting set indicates
the thread has a pending patch which needs to be applied when the thread
exits the kernel.
The bit is placed in the _TIF_ALLWORK_MASK macro, which results in
exit_to_usermode_loop() calling klp_update_patch_state() when it's set.
Signed-off-by: Josh Poimboeuf <redacted>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-16 16:01:09
On Thu 2016-12-08 12:08:30, Josh Poimboeuf wrote:
Add the TIF_PATCH_PENDING thread flag to enable the new livepatch
per-task consistency model for powerpc. The bit getting set indicates
the thread has a pending patch which needs to be applied when the thread
exits the kernel.
The bit is included in the _TIF_USER_WORK_MASK macro so that
do_notify_resume() and klp_update_patch_state() get called when the bit
is set.
Signed-off-by: Josh Poimboeuf <redacted>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-16 16:21:05
On Thu 2016-12-08 12:08:33, Josh Poimboeuf wrote:
Once we have a consistency model, patches and their objects will be
enabled and disabled at different times. For example, when a patch is
disabled, its loaded objects' funcs can remain registered with ftrace
indefinitely until the unpatching operation is complete and they're no
longer in use.
It's less confusing if we give them different names: patches can be
enabled or disabled; objects (and their funcs) can be patched or
unpatched:
- Enabled means that a patch is logically enabled (but not necessarily
fully applied).
- Patched means that an object's funcs are registered with ftrace and
added to the klp_ops func stack.
Also, since these states are binary, represent them with booleans
instead of ints.
Signed-off-by: Josh Poimboeuf <redacted>
Makes sense. The patch is pretty straightforward.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-16 16:27:02
On Thu 2016-12-08 12:08:34, Josh Poimboeuf wrote:
klp_patch_object()'s callers already ensure that the object is loaded,
so its call to klp_is_object_loaded() is unnecessary.
This will also make it possible to move the patching code into a
separate file.
Fair enough.
Signed-off-by: Josh Poimboeuf <redacted>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-16 16:56:07
On Thu 2016-12-08 12:08:36, Josh Poimboeuf wrote:
quoted hunk
The sysfs enabled value is a boolean, so kstrtobool() is a better fit
for parsing the input string since it does the range checking for us.
Suggested-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Josh Poimboeuf <redacted>
---
kernel/livepatch/core.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
On Fri, Dec 16, 2016 at 02:07:39PM +0100, Petr Mladek wrote:
On Thu 2016-12-08 12:08:26, Josh Poimboeuf wrote:
quoted
For live patching and possibly other use cases, a stack trace is only
useful if it can be assured that it's completely reliable. Add a new
save_stack_trace_tsk_reliable() function to achieve that.
Scenarios which indicate that a stack trace may be unreliable:
- running task
It seems that this has to be enforced by save_stack_trace_tsk_reliable()
caller. It should be mentioned in the function description.
Agreed.
quoted
- interrupt stack
I guess that it is detected by saved regs on the stack. And it covers
also dynamic changes like kprobes. Do I get it correctly, please?
Right.
What about ftrace? Is ftrace without regs safe and detected?
Yes, it's safe because the mcount code does the right thing with respect
to frame pointers. See save_mcount_regs().
quoted
- preemption
I wonder if some very active kthreads might almost always be
preempted using irq in preemptive kernel. Then they block
the conversion with the non-reliable stacks. Have you noticed
such problems, please?
I haven't seen such a case and I think it would be quite rare for a
kthread to be CPU-bound like that.
quoted
- corrupted stack data
- stack grows the wrong way
This is detected in unwind_next_frame() and passed via state->error.
Am I right?
Right. I'll add more details to the commit message for all of these.
quoted
- stack walk doesn't reach the bottom
- user didn't provide a large enough entries array
Also add CONFIG_HAVE_RELIABLE_STACKTRACE so arch-independent code can
determine at build time whether the function is implemented.
By other words, it we find regs on the stack, it almost always mean
a non-reliable stack. The only exception is when we are in the
userspace mode. Do I get it correctly, please?
Right.
quoted
+
+ /*
+ * This frame contains the (user mode) pt_regs at the
+ * end of the stack. Finish the unwind.
+ */
+ unwind_next_frame(&state);
+ break;
+ }
+
+ addr = unwind_get_return_address(&state);
+ if (!addr || save_stack_address(trace, addr, false))
+ return -1;
+ }
+
+ if (!unwind_done(&state) || unwind_error(&state))
+ return -1;
+
+ if (trace->nr_entries < trace->max_entries)
+ trace->entries[trace->nr_entries++] = ULONG_MAX;
+
+ return 0;
+}
Great work! I am surprised that it looks so straightforward.
I still have to think and investigate it more. But it looks
very promissing.
Best Regards,
Petr
On Fri, Dec 16, 2016 at 03:17:35PM +0100, Petr Mladek wrote:
On Thu 2016-12-08 12:08:27, Josh Poimboeuf wrote:
quoted
The _TIF_ALLWORK_MASK macro automatically includes the least-significant
16 bits of the thread_info flags, which is less than obvious and tends
to create confusion and surprises when reading or modifying the code.
Define the flags explicitly.
Signed-off-by: Josh Poimboeuf <redacted>
---
arch/x86/include/asm/thread_info.h | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
Yup, this is not true because also some flags from the most
significant bits are in the _TIF_ALLWORK_MASK.
quoted
- * - other flags in MSW
- * Warning: layout of LSW is hardcoded in entry.S
*/
#define TIF_SYSCALL_TRACE 0 /* syscall trace active */
#define TIF_NOTIFY_RESUME 1 /* callback before returning to user */
@@ -133,8 +130,10 @@ struct thread_info { /* work to do on any return to user space */ #define _TIF_ALLWORK_MASK \- ((0x0000FFFF & ~_TIF_SECCOMP) | _TIF_SYSCALL_TRACEPOINT | \- _TIF_NOHZ)+ (_TIF_SYSCALL_TRACE | _TIF_NOTIFY_RESUME | _TIF_SIGPENDING | \+ _TIF_SINGLESTEP | _TIF_NEED_RESCHED | _TIF_SYSCALL_EMU | \+ _TIF_SYSCALL_AUDIT | _TIF_USER_RETURN_NOTIFY | _TIF_UPROBE | \+ _TIF_SYSCALL_TRACEPOINT | _TIF_NOHZ)
All flags are sorted by the number except for
_TIF_SINGLESTEP and _TIF_NEED_RESCHED ;-)
You're right, I'll swap them :-)
The patch does not change the existing behavior. The same
existing flags are listed.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
On Fri, Dec 16, 2016 at 03:41:59PM +0100, Petr Mladek wrote:
On Thu 2016-12-08 12:08:28, Josh Poimboeuf wrote:
quoted
Create temporary stubs for klp_patch_pending() and
klp_update_patch_state() so we can add TIF_PATCH_PENDING to different
architectures in separate patches without breaking build bisectability.
Signed-off-by: Josh Poimboeuf <redacted>
---
include/linux/livepatch.h | 7 ++++++-
kernel/livepatch/core.c | 3 +++
2 files changed, 9 insertions(+), 1 deletion(-)
It seems that the stub for this function is enough.
Well, the extra function is just a cosmetic problem. If it could be
fixed, it would be great. But the patch makes sense:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
On Fri, Dec 16, 2016 at 05:55:55PM +0100, Petr Mladek wrote:
On Thu 2016-12-08 12:08:36, Josh Poimboeuf wrote:
quoted
The sysfs enabled value is a boolean, so kstrtobool() is a better fit
for parsing the input string since it does the range checking for us.
Suggested-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Josh Poimboeuf <redacted>
---
kernel/livepatch/core.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-19 13:10:42
On Thu 2016-12-08 12:08:37, Josh Poimboeuf wrote:
For the consistency model we'll need to know the sizes of the old and
new functions to determine if they're on the stacks of any tasks.
Signed-off-by: Josh Poimboeuf <redacted>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
Tests to measure possible performance penalty of frame pointers were done
by Mel Gorman. The outcome was quite clear. There IS a measurable
impact. The percentage depends on the workflow but I think it is safe to
say that FP usually takes 5-10 percents.
If my understanding is correct there is no single culprit. Register
pressure is definitely not a problem. We ran simple benchmarks while
taking a register away from GCC (RBP or a common one). The impact is a
combination of more cacheline pressure, more memory accesses and the fact
that the kernel contains a lot of small functions.
Thus, I think that DWARF should be the way to go here.
Other than that the patch looks good to me.
Miroslav
From: Miroslav Benes <mbenes@suse.cz> Date: 2016-12-19 16:40:00
On Thu, 8 Dec 2016, Josh Poimboeuf wrote:
The _TIF_ALLWORK_MASK macro automatically includes the least-significant
16 bits of the thread_info flags, which is less than obvious and tends
to create confusion and surprises when reading or modifying the code.
Yes.
Define the flags explicitly.
Signed-off-by: Josh Poimboeuf <redacted>
With _TIF_SINGLESTEP and _TIF_NEED_RESCHED swapped you can add my
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Miroslav
@@ -73,9 +73,6 @@ struct thread_info {*threadinformationflags*-theseareprocessstateflagsthatvariousassemblyfiles*mayneedtoaccess-*-pendingwork-to-be-doneflagsareinLSW-*-otherflagsinMSW-*Warning:layoutofLSWishardcodedinentry.S*/#define TIF_SYSCALL_TRACE 0 /* syscall trace active */#define TIF_NOTIFY_RESUME 1 /* callback before returning to user */
@@ -133,8 +130,10 @@ struct thread_info {/* work to do on any return to user space */#define _TIF_ALLWORK_MASK \-((0x0000FFFF&~_TIF_SECCOMP)|_TIF_SYSCALL_TRACEPOINT|\-_TIF_NOHZ)+(_TIF_SYSCALL_TRACE|_TIF_NOTIFY_RESUME|_TIF_SIGPENDING|\+_TIF_SINGLESTEP|_TIF_NEED_RESCHED|_TIF_SYSCALL_EMU|\+_TIF_SYSCALL_AUDIT|_TIF_USER_RETURN_NOTIFY|_TIF_UPROBE|\+_TIF_SYSCALL_TRACEPOINT|_TIF_NOHZ)/* flags to check in __switch_to() */#define _TIF_WORK_CTXSW \
Tests to measure possible performance penalty of frame pointers were done
by Mel Gorman. The outcome was quite clear. There IS a measurable
impact. The percentage depends on the workflow but I think it is safe to
say that FP usually takes 5-10 percents.
If my understanding is correct there is no single culprit. Register
pressure is definitely not a problem. We ran simple benchmarks while
taking a register away from GCC (RBP or a common one). The impact is a
combination of more cacheline pressure, more memory accesses and the fact
that the kernel contains a lot of small functions.
Thus, I think that DWARF should be the way to go here.
Other than that the patch looks good to me.
I agree that DWARF is generally a good idea, and I'm working toward it.
However there's still quite a bit of work to get there.
For this consistency model to work with DWARF on x86, we would need:
1) a reliable x86 DWARF unwinder with Linus's blessing
2) objtool DWARF support (I'm working on this at the moment)
3) probably some kind of runtime NMI stack checking feature to
complement objtool, along with a lot of burn time to ensure there are
no issues, particularly in entry code
4) port save_stack_trace_tsk_reliable() to work with DWARF
DWARF will be nice to have, but it's definitely not required before
merging this consistency model.
Also I doubt we'll ever be able to drop frame pointer support
completely. Some embedded systems may not want the overhead of the
DWARF metadata.
--
Josh
Tests to measure possible performance penalty of frame pointers were done
by Mel Gorman. The outcome was quite clear. There IS a measurable
impact. The percentage depends on the workflow but I think it is safe to
say that FP usually takes 5-10 percents.
If my understanding is correct there is no single culprit. Register
pressure is definitely not a problem. We ran simple benchmarks while
taking a register away from GCC (RBP or a common one). The impact is a
combination of more cacheline pressure, more memory accesses and the fact
that the kernel contains a lot of small functions.
Thus, I think that DWARF should be the way to go here.
Other than that the patch looks good to me.
I agree that DWARF is generally a good idea, and I'm working toward it.
However there's still quite a bit of work to get there.
For this consistency model to work with DWARF on x86, we would need:
1) a reliable x86 DWARF unwinder with Linus's blessing
2) objtool DWARF support (I'm working on this at the moment)
3) probably some kind of runtime NMI stack checking feature to
complement objtool, along with a lot of burn time to ensure there are
no issues, particularly in entry code
4) port save_stack_trace_tsk_reliable() to work with DWARF
Yes, this is a lot of work to do.
DWARF will be nice to have, but it's definitely not required before
merging this consistency model.
Oh, I didn't mean it to be done before merging this patch set. Sorry for
the confusion. The point was that as long as the performance is involved
FP does not look that promising and DWARF could be better (but who knows,
right?).
Also I doubt we'll ever be able to drop frame pointer support
completely. Some embedded systems may not want the overhead of the
DWARF metadata.
True. There should be a choice in this respect.
Regards,
Miroslav
Tests to measure possible performance penalty of frame pointers were done
by Mel Gorman. The outcome was quite clear. There IS a measurable
impact. The percentage depends on the workflow but I think it is safe to
say that FP usually takes 5-10 percents.
If my understanding is correct there is no single culprit. Register
pressure is definitely not a problem. We ran simple benchmarks while
taking a register away from GCC (RBP or a common one). The impact is a
combination of more cacheline pressure, more memory accesses and the fact
that the kernel contains a lot of small functions.
Thus, I think that DWARF should be the way to go here.
Other than that the patch looks good to me.
I agree that DWARF is generally a good idea, and I'm working toward it.
However there's still quite a bit of work to get there.
For this consistency model to work with DWARF on x86, we would need:
1) a reliable x86 DWARF unwinder with Linus's blessing
2) objtool DWARF support (I'm working on this at the moment)
3) probably some kind of runtime NMI stack checking feature to
complement objtool, along with a lot of burn time to ensure there are
no issues, particularly in entry code
Could you please provide more details about this NMI stack checking?
What is it supposed to protect that objtool could not?
Will it run regularly or will it be just a random check?
The other points are obvious. But I do not know what to
think about this NMI thing. And so I am curious :-)
4) port save_stack_trace_tsk_reliable() to work with DWARF
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-20 17:32:52
On Thu 2016-12-08 12:08:38, Josh Poimboeuf wrote:
quoted hunk
Change livepatch to use a basic per-task consistency model. This is the
foundation which will eventually enable us to patch those ~10% of
security patches which change function or data semantics. This is the
biggest remaining piece needed to make livepatch more generally useful.
[1] https://lkml.kernel.org/r/20141107140458.GA21774@suse.cz
Signed-off-by: Josh Poimboeuf <redacted>
---
I like the description.
Just a note that we will also need to review the section about
limitations. But I am not sure that we want to do it in this patch.
It might open a long discussion on its own.
There are more checks possible. I would use the same description
as for klp_object.
quoted hunk
* @old_addr: the address of the function being patched
* @kobj: kobject for sysfs resources
* @stack_node: list node for klp_ops func_stack list
* @old_size: size of the old function
* @new_size: size of the new function
* @patched: the func has been added to the klp_ops list
+ * @transition: the func is currently being applied or reverted
+ *
@@ -86,6 +110,7 @@ struct klp_object { * struct klp_patch - patch structure for live patching * @mod: reference to the live patch module * @objs: object entries for kernel objects to be patched+ * @immediate: patch all funcs immediately, bypassing safety mechanisms * @list: list node for global list of registered patches * @kobj: kobject for sysfs resources * @enabled: the patch is enabled (but operation may be incomplete)
I would put this mod_delayed_work() into klp_reverse_transition().
Also I would put that schedule_delayed_work() into
klp_try_complete_transition().
If I did not miss anything, it will allow to move the
klp_transition_work code to transition.c where it logically
belongs.
+ } else if (enabled) {
ret = __klp_enable_patch(patch);
if (ret)
goto err;
@@ -54,15 +55,53 @@ static void notrace klp_ftrace_handler(unsigned long ip,{structklp_ops*ops;structklp_func*func;+intpatch_state;ops=container_of(fops,structklp_ops,fops);rcu_read_lock();+func=list_first_or_null_rcu(&ops->func_stack,structklp_func,stack_node);-if(WARN_ON_ONCE(!func))++if(!func)gotounlock;
Why do you removed the WARN_ON_ONCE(), please?
We still add the function on the stack before registering
the ftrace handler. Also we unregister the ftrace handler
before removing the the last entry from the stack.
AFAIK, unregister_ftrace_function() calls rcu_synchronize()'
to make sure that no-one is inside the handler once finished.
Mirek knows more about it.
If this is not true, we have a problem. For example,
we call kfree(ops) after unregister_ftrace_function();
BTW: I thought that this change was really needed because of
klp_try_complete_transition(). But I think that the WARN
could and should stay after all. See below.
+ /*
+ * Enforce the order of the ops->func_stack and func->transition reads.
+ * The corresponding write barrier is in __klp_enable_patch().
+ */
+ smp_rmb();
+
+ if (unlikely(func->transition)) {
+
+ /*
+ * Enforce the order of the func->transition and
+ * current->patch_state reads. Otherwise we could read an
+ * out-of-date task state and pick the wrong function. The
+ * corresponding write barriers are in klp_init_transition()
+ * and __klp_disable_patch().
+ */
+ smp_rmb();
+
+ patch_state = current->patch_state;
+
+ WARN_ON_ONCE(patch_state == KLP_UNDEFINED);
+
+ if (patch_state == KLP_UNPATCHED) {
+ /*
+ * Use the previously patched version of the function.
+ * If no previous patches exist, use the original
+ * function.
@@ -0,0 +1,479 @@+/*+ * transition.c - Kernel Live Patching transition functions+ *+ * Copyright (C) 2015-2016 Josh Poimboeuf <jpoimboe@redhat.com>+ *+ * 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+ * along with this program; if not, see <http://www.gnu.org/licenses/>.+ */++#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt++#include <linux/cpu.h>+#include <linux/stacktrace.h>+#include "patch.h"+#include "transition.h"+#include "../sched/sched.h"
Is this acceptable for the scheduler guys?
+#define MAX_STACK_ENTRIES 100
+
+struct klp_patch *klp_transition_patch;
+
+static int klp_target_state = KLP_UNDEFINED;
+
+/* called from copy_process() during fork */
+void klp_copy_process(struct task_struct *child)
+{
+ child->patch_state = current->patch_state;
+
+ /* TIF_PATCH_PENDING gets copied in setup_thread_stack() */
+}
+
+/*
+ * klp_update_patch_state() - change the patched state of a task
+ * @task: The task to change
+ *
+ * Switches the patched state of the task to the set of functions in the target
+ * patch state.
+ */
Please, add here some warning. Something like:
* This function must never be called in parallel with
* klp_ftrace_handler(). Otherwise, the handler might do random
* decisions and break the consistency.
*
* By other words, call this function only by the @task itself
* or make sure that it is not running.
+void klp_update_patch_state(struct task_struct *task)
+{
+ /*
+ * The synchronize_rcu() call in klp_try_complete_transition() ensures
+ * this critical section completes before the global patch transition
+ * is considered complete so we don't have spurious patch_state updates
+ * afterwards.
+ */
+ rcu_read_lock();
+
+ /*
+ * This test_and_clear_tsk_thread_flag() call also serves as a read
+ * barrier to enforce the order of the TIF_PATCH_PENDING and
+ * klp_target_state reads. The corresponding write barriers are in
+ * __klp_disable_patch() and klp_reverse_transition().
+ */
+ if (test_and_clear_tsk_thread_flag(task, TIF_PATCH_PENDING))
+ task->patch_state = READ_ONCE(klp_target_state);
+
+ rcu_read_unlock();
+}
+
+/*
+ * Initialize the global target patch state and all tasks to the initial patch
+ * state, and initialize all function transition states to true in preparation
+ * for patching or unpatching.
+ */
+void klp_init_transition(struct klp_patch *patch, int state)
+{
+ struct task_struct *g, *task;
+ unsigned int cpu;
+ struct klp_object *obj;
+ struct klp_func *func;
+ int initial_state = !state;
+
+ WARN_ON_ONCE(klp_target_state != KLP_UNDEFINED);
+
+ klp_transition_patch = patch;
+
+ /*
+ * Set the global target patch state which tasks will switch to. This
+ * has no effect until the TIF_PATCH_PENDING flags get set later.
+ */
+ klp_target_state = state;
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (patch->immediate)
+ return;
+
+ /*
+ * Initialize all tasks to the initial patch state to prepare them for
+ * switching to the target state.
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task) {
+ WARN_ON_ONCE(task->patch_state != KLP_UNDEFINED);
+ task->patch_state = initial_state;
+ }
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks.
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu) {
+ task = idle_task(cpu);
+ WARN_ON_ONCE(task->patch_state != KLP_UNDEFINED);
+ task->patch_state = initial_state;
+ }
+ put_online_cpus();
We allow to add/remove CPUs here. I am afraid that we will also need
to add a cpu coming/going handler that will set the task->patch_state
the right way. We must not set the klp_target_state until all ftrace
handlers are ready.
+ /*
+ * Enforce the order of the task->patch_state initializations and the
+ * func->transition updates to ensure that, in the enable path,
+ * klp_ftrace_handler() doesn't see a func in transition with a
+ * task->patch_state of KLP_UNDEFINED.
+ */
+ smp_wmb();
+
+ /*
+ * Set the func transition states so klp_ftrace_handler() will know to
+ * switch to the transition logic.
+ *
+ * When patching, the funcs aren't yet in the func_stack and will be
+ * made visible to the ftrace handler shortly by the calls to
+ * klp_patch_object().
+ *
+ * When unpatching, the funcs are already in the func_stack and so are
+ * already visible to the ftrace handler.
+ */
+ klp_for_each_object(patch, obj)
+ klp_for_each_func(obj, func)
+ func->transition = true;
+}
+
+/*
+ * Start the transition to the specified target patch state so tasks can begin
+ * switching to it.
+ */
+void klp_start_transition(void)
+{
+ struct task_struct *g, *task;
+ unsigned int cpu;
+
+ WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
+
+ pr_notice("'%s': %s...\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (klp_transition_patch->immediate)
+ return;
+
+ /*
+ * Mark all normal tasks as needing a patch state update. As they pass
+ * through the syscall barrier they'll switch over to the target state
+ * (unless we switch them in klp_try_complete_transition() first).
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task)
+ set_tsk_thread_flag(task, TIF_PATCH_PENDING);
This is called also from klp_reverse_transition(). We should set it
only when the task need migration. Also we should clear it when
the task is in the right state already.
It is not only optimization. It actually solves a race between
klp_complete_transition() and klp_update_patch_state(), see below.
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks, though they never cross the
+ * syscall barrier. Instead they switch over in cpu_idle_loop().
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu)
+ set_tsk_thread_flag(idle_task(cpu), TIF_PATCH_PENDING);
+ put_online_cpus();
Also this stage need to be somehow handled by CPU coming/going
handlers.
+}
+
+/*
+ * The transition to the target patch state is complete. Clean up the data
+ * structures.
+ */
+void klp_complete_transition(void)
+{
+ struct klp_object *obj;
+ struct klp_func *func;
+ struct task_struct *g, *task;
+ unsigned int cpu;
+
+ if (klp_transition_patch->immediate)
+ goto done;
+
+ klp_for_each_object(klp_transition_patch, obj)
+ klp_for_each_func(obj, func)
+ func->transition = false;
We should call rcu_synchronize() here. Otherwise, there
might be a race, see below:
CPU1 CPU2
klp_ftrace_handler()
if (unlikely(func->transition))
// still true
klp_complete_transition()
func->transition = false;
task->patch_state =
KLP_UNDEFINED;
patch_state = current->patch_state;
WARN_ON(patch_state == KLP_UNDEFINED);
BANG!: We print the warning.
Note that that smp_wmb() is enough in klp_init_transition()
but it is not enough here. We need to wait longer once
someone might be inside the if (true) code.
If TIF_PATCH_PENDING flag is set here it means that
klp_update_patch_state() might get triggered and it might
put wrong value into task->patch_state.
We must make sure that all task have this cleared before
calling this function. This is another reason why
klp_init_transition() should set the flag only when
transition is needed.
We should only check the state here.
It still might make sense to clear it when it is set wrongly.
But the question is if it is really safe to continue. I am
afraid that it is not. It would mean that the consistency
model is broken and we are in strange state.
+
+/*
+ * Try to switch all remaining tasks to the target patch state by walking the
+ * stacks of sleeping tasks and looking for any to-be-patched or
+ * to-be-unpatched functions. If such functions are found, the task can't be
+ * switched yet.
+ *
+ * If any tasks are still stuck in the initial patch state, schedule a retry.
+ */
+bool klp_try_complete_transition(void)
+{
+ unsigned int cpu;
+ struct task_struct *g, *task;
+ bool complete = true;
+
+ WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (klp_transition_patch->immediate)
+ goto success;
+
+ /*
+ * Try to switch the tasks to the target patch state by walking their
+ * stacks and looking for any to-be-patched or to-be-unpatched
+ * functions. If such functions are found on a stack, or if the stack
+ * is deemed unreliable, the task can't be switched yet.
+ *
+ * Usually this will transition most (or all) of the tasks on a system
+ * unless the patch includes changes to a very common function.
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task)
+ if (!klp_try_switch_task(task))
+ complete = false;
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks.
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu)
+ if (!klp_try_switch_task(idle_task(cpu)))
+ complete = false;
+ put_online_cpus();
+
+ /*
+ * Some tasks weren't able to be switched over. Try again later and/or
+ * wait for other methods like syscall barrier switching.
+ */
+ if (!complete)
+ return false;
+
+success:
+
+ /*
+ * When unpatching, all tasks have transitioned to KLP_UNPATCHED so we
+ * can now remove the new functions from the func_stack.
+ */
+ if (klp_target_state == KLP_UNPATCHED)
+ klp_unpatch_objects(klp_transition_patch);
+
+ /*
+ * Wait for all RCU read-side critical sections to complete.
+ *
+ * This has two purposes:
+ *
+ * 1) Ensure all existing critical sections in klp_update_patch_state()
+ * complete, so task->patch_state won't be unexpectedly updated
+ * later.
We should not be here if anyone still might be in klp_update_patch_state().
+ *
+ * 2) When unpatching, don't allow any existing instances of
+ * klp_ftrace_handler() to access any obsolete funcs before we reset
+ * the func transition states to false. Otherwise the handler may
+ * see the deleted "new" func, see that it's not in transition, and
+ * wrongly pick the new version of the function.
+ */
This makes sense but it too me long time to understand. I wonder if
this might be better:
/*
* Make sure that the function is removed from ops->func_stack
* before we clear func->transition. Otherwise the handler may
* pick the wrong version.
*/
And I would call this only when the patch is being removed
if (klp_target_state = KLP_UNPATCHED)
synchronize_rcu();
I think that this was the reason to remove WARN_ON_ONCE(!func)
in klp_ftrace_handler(). But this is not related. If this was
the last entry in the list, we removed the ftrace_handler
before removing the last entry. And unregister_ftrace_function()
calls rcu_synchronize() to prevent calling the handler later.
+ synchronize_rcu();
+
+ pr_notice("'%s': %s complete\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
+ /* we're done, now cleanup the data structures */
+ klp_complete_transition();
+
+ return true;
+}
+
+/*
+ * This function can be called in the middle of an existing transition to
+ * reverse the direction of the target patch state. This can be done to
+ * effectively cancel an existing enable or disable operation if there are any
+ * tasks which are stuck in the initial patch state.
+ */
+void klp_reverse_transition(void)
+{
+ klp_transition_patch->enabled = !klp_transition_patch->enabled;
+
+ klp_target_state = !klp_target_state;
+
+ /*
+ * Enforce the order of the write to klp_target_state above and the
+ * TIF_PATCH_PENDING writes in klp_start_transition() to ensure that
+ * klp_update_patch_state() doesn't set a wrong task->patch_state.
+ */
+ smp_wmb();
I would call rcu_synchronize() here to make sure that
klp_update_patch_state() calls will not set
an outdated task->patch_state.
Note that smp_wmb() is not enough. We do not check TIF_PATCH_PENDING
in klp_try_switch_task(). There is a tiny race:
CPU1 CPU2
klp_update_patch_state()
if (test_and clear(task, TIF)
READ_ONCE(klp_target_state);
mutex_lock(klp_lock);
klp_reverse_transition()
klp_target_state =
!klp_target_state;
klp_start_transition()
mutex_unlock(klp_lock);
<switch to another process>
klp_transition_work_fn()
mutex_lock(klp_lock);
klp_try_complete_transition()
klp_try_switch_task()
if (task->patch_state ==
klp_target_state)
return true;
task->patch_state = <outdated_value>;
klp_ftrace_handler()
BANG: klp_ftrace_handler() will use wrong implementation according
to the outdated task->patch_state. At the same time,
klp_transition() is not blocked by the task because it thinks
that it has a correct state.
@@ -69,6 +71,11 @@ static int livepatch_init(void){intret;+if(!klp_have_reliable_stack()&&!patch.immediate){+pr_notice("disabling consistency model!\n");+patch.immediate=true;+}
I am scared to have this in the sample module. It makes sense
to use the consistency model even for immediate patches because
it allows to remove them. But this must not be used for patches
that really require the consistency model. We should add
a big fat warning at least.
+
ret = klp_register_patch(&patch);
if (ret)
return ret;
I like the patch. All the problems that I found look solvable.
I think that we are on the right way.
Best Regards,
Petr
On Tue, Dec 20, 2016 at 10:39:16AM +0100, Petr Mladek wrote:
On Mon 2016-12-19 11:25:49, Josh Poimboeuf wrote:
quoted
3) probably some kind of runtime NMI stack checking feature to
complement objtool, along with a lot of burn time to ensure there are
no issues, particularly in entry code
Could you please provide more details about this NMI stack checking?
What is it supposed to protect that objtool could not?
Will it run regularly or will it be just a random check?
save_stack_trace_tsk_reliable(current) would be called periodically from
an NMI handler, and a warning would be printed if it ever doesn't reach
the "end" of the stack (i.e., user-mode pt_regs). Due to the
performance impact it would probably only be a debug option.
It would verify the special hand-coded areas which objtool isn't smart
enough to understand, like entry code, ftrace, kprobes, bpf. It would
also make sure that objtool itself didn't missing anything.
--
Josh
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-21 11:20:59
On Thu 2016-12-08 12:08:39, Josh Poimboeuf wrote:
Expose the per-task patch state value so users can determine which tasks
are holding up completion of a patching operation.
Signed-off-by: Josh Poimboeuf <redacted>
Makes sense.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
From: Miroslav Benes <mbenes@suse.cz> Date: 2016-12-21 13:54:25
On Thu, 8 Dec 2016, Josh Poimboeuf wrote:
Add the TIF_PATCH_PENDING thread flag to enable the new livepatch
per-task consistency model for x86_64. The bit getting set indicates
the thread has a pending patch which needs to be applied when the thread
exits the kernel.
The bit is placed in the _TIF_ALLWORK_MASK macro, which results in
exit_to_usermode_loop() calling klp_update_patch_state() when it's set.
Signed-off-by: Josh Poimboeuf <redacted>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Miroslav
From: Miroslav Benes <mbenes@suse.cz> Date: 2016-12-21 14:30:41
On Thu, 8 Dec 2016, Josh Poimboeuf wrote:
Add the TIF_PATCH_PENDING thread flag to enable the new livepatch
per-task consistency model for powerpc. The bit getting set indicates
the thread has a pending patch which needs to be applied when the thread
exits the kernel.
The bit is included in the _TIF_USER_WORK_MASK macro so that
do_notify_resume() and klp_update_patch_state() get called when the bit
is set.
Signed-off-by: Josh Poimboeuf <redacted>
Looks good to me. You can add my
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Miroslav
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-21 14:44:40
On Thu 2016-12-08 12:08:40, Josh Poimboeuf wrote:
From: Miroslav Benes <mbenes@suse.cz>
Currently we do not allow patch module to unload since there is no
method to determine if a task is still running in the patched code.
The consistency model gives us the way because when the unpatching
finishes we know that all tasks were marked as safe to call an original
function. Thus every new call to the function calls the original code
and at the same time no task can be somewhere in the patched code,
because it had to leave that code to be marked as safe.
[...]
Also all kobject_put(&patch->kobj) calls are moved outside of klp_mutex
lock protection to prevent a deadlock situation when
klp_unregister_patch is called and sysfs directories are removed.
is no need to do the same for other kobject_put() callsites as we
currently do not have their sysfs counterparts.
Heh, we have spent huge amount of time on this. I think
that it deserves a more precise description ;-). What about?
Finally, we need to be very careful about possible races between
klp_unregister_patch(), kobject_put() functions and operations
on the related sysfs files.
kobject_put(&patch->kobj) must be called without klp_mutex. Otherwise,
it might be blocked by enabled_store() that needs the mutex as well.
In addition, enabled_store() must check if the patch was not
unregisted in the meantime.
There is no need to do the same for other kobject_put() callsites
at the moment. Their sysfs operations neiter take the lock nor
they access any data that might be freed in the meantime.
There was an attempt to use kobjects the right way and prevent these
races by design. But it made the patch definition more complicated
and opened another can of worms. See
https://lkml.kernel.org/r/1464018848-4303-1-git-send-email-pmladek@suse.com
Signed-off-by: Miroslav Benes <mbenes@suse.cz>
Signed-off-by: Josh Poimboeuf <redacted>
Otherwise, it seems correct. We have already analyzed this to the death.
I do not see new problems with a fresh look.
With the above, or comparable, change in the commit message:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
From: Miroslav Benes <mbenes@suse.cz> Date: 2016-12-21 15:29:25
On Thu, 8 Dec 2016, Josh Poimboeuf wrote:
From: Jiri Slaby <redacted>
Group the TIF thread flag bits by their inclusion in the _TIF_WORK and
_TIF_TRACE macros.
Signed-off-by: Jiri Slaby <redacted>
Signed-off-by: Josh Poimboeuf <redacted>
I believe there is no harm doing that and we need it for
_TIF_PATCH_PENDING later.
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Miroslav
On Tue, Dec 20, 2016 at 06:32:46PM +0100, Petr Mladek wrote:
On Thu 2016-12-08 12:08:38, Josh Poimboeuf wrote:
quoted
Change livepatch to use a basic per-task consistency model. This is the
foundation which will eventually enable us to patch those ~10% of
security patches which change function or data semantics. This is the
biggest remaining piece needed to make livepatch more generally useful.
[1] https://lkml.kernel.org/r/20141107140458.GA21774@suse.cz
Signed-off-by: Josh Poimboeuf <redacted>
---
I like the description.
Just a note that we will also need to review the section about
limitations. But I am not sure that we want to do it in this patch.
It might open a long discussion on its own.
There are more checks possible. I would use the same description
as for klp_object.
Agreed.
quoted
* @old_addr: the address of the function being patched
* @kobj: kobject for sysfs resources
* @stack_node: list node for klp_ops func_stack list
* @old_size: size of the old function
* @new_size: size of the new function
* @patched: the func has been added to the klp_ops list
+ * @transition: the func is currently being applied or reverted
+ *
@@ -86,6 +110,7 @@ struct klp_object { * struct klp_patch - patch structure for live patching * @mod: reference to the live patch module * @objs: object entries for kernel objects to be patched+ * @immediate: patch all funcs immediately, bypassing safety mechanisms * @list: list node for global list of registered patches * @kobj: kobject for sysfs resources * @enabled: the patch is enabled (but operation may be incomplete)
I would put this mod_delayed_work() into klp_reverse_transition().
Also I would put that schedule_delayed_work() into
klp_try_complete_transition().
If I did not miss anything, it will allow to move the
klp_transition_work code to transition.c where it logically
belongs.
Makes sense, I'll see if I can move all the klp_transition_work code to
transition.c.
quoted
+ } else if (enabled) {
ret = __klp_enable_patch(patch);
if (ret)
goto err;
@@ -54,15 +55,53 @@ static void notrace klp_ftrace_handler(unsigned long ip,{structklp_ops*ops;structklp_func*func;+intpatch_state;ops=container_of(fops,structklp_ops,fops);rcu_read_lock();+func=list_first_or_null_rcu(&ops->func_stack,structklp_func,stack_node);-if(WARN_ON_ONCE(!func))++if(!func)gotounlock;
Why do you removed the WARN_ON_ONCE(), please?
We still add the function on the stack before registering
the ftrace handler. Also we unregister the ftrace handler
before removing the the last entry from the stack.
AFAIK, unregister_ftrace_function() calls rcu_synchronize()'
to make sure that no-one is inside the handler once finished.
Mirek knows more about it.
Hm, this is news to me. Mirek, please share :-)
If this is not true, we have a problem. For example,
we call kfree(ops) after unregister_ftrace_function();
Agreed.
BTW: I thought that this change was really needed because of
klp_try_complete_transition(). But I think that the WARN
could and should stay after all. See below.
quoted
+ /*
+ * Enforce the order of the ops->func_stack and func->transition reads.
+ * The corresponding write barrier is in __klp_enable_patch().
+ */
+ smp_rmb();
+
+ if (unlikely(func->transition)) {
+
+ /*
+ * Enforce the order of the func->transition and
+ * current->patch_state reads. Otherwise we could read an
+ * out-of-date task state and pick the wrong function. The
+ * corresponding write barriers are in klp_init_transition()
+ * and __klp_disable_patch().
+ */
+ smp_rmb();
+
+ patch_state = current->patch_state;
+
+ WARN_ON_ONCE(patch_state == KLP_UNDEFINED);
+
+ if (patch_state == KLP_UNPATCHED) {
+ /*
+ * Use the previously patched version of the function.
+ * If no previous patches exist, use the original
+ * function.
@@ -0,0 +1,479 @@+/*+ * transition.c - Kernel Live Patching transition functions+ *+ * Copyright (C) 2015-2016 Josh Poimboeuf <jpoimboe@redhat.com>+ *+ * 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+ * along with this program; if not, see <http://www.gnu.org/licenses/>.+ */++#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt++#include <linux/cpu.h>+#include <linux/stacktrace.h>+#include "patch.h"+#include "transition.h"+#include "../sched/sched.h"
Is this acceptable for the scheduler guys?
I discussed the use of task_rq_lock() with Peter Zijlstra on IRC and he
seemed to think it was ok. Peter, please speak up if you disagree :-)
quoted
+#define MAX_STACK_ENTRIES 100
+
+struct klp_patch *klp_transition_patch;
+
+static int klp_target_state = KLP_UNDEFINED;
+
+/* called from copy_process() during fork */
+void klp_copy_process(struct task_struct *child)
+{
+ child->patch_state = current->patch_state;
+
+ /* TIF_PATCH_PENDING gets copied in setup_thread_stack() */
+}
+
+/*
+ * klp_update_patch_state() - change the patched state of a task
+ * @task: The task to change
+ *
+ * Switches the patched state of the task to the set of functions in the target
+ * patch state.
+ */
Please, add here some warning. Something like:
* This function must never be called in parallel with
* klp_ftrace_handler(). Otherwise, the handler might do random
* decisions and break the consistency.
*
* By other words, call this function only by the @task itself
* or make sure that it is not running.
+void klp_update_patch_state(struct task_struct *task)
+{
+ /*
+ * The synchronize_rcu() call in klp_try_complete_transition() ensures
+ * this critical section completes before the global patch transition
+ * is considered complete so we don't have spurious patch_state updates
+ * afterwards.
+ */
+ rcu_read_lock();
+
+ /*
+ * This test_and_clear_tsk_thread_flag() call also serves as a read
+ * barrier to enforce the order of the TIF_PATCH_PENDING and
+ * klp_target_state reads. The corresponding write barriers are in
+ * __klp_disable_patch() and klp_reverse_transition().
+ */
+ if (test_and_clear_tsk_thread_flag(task, TIF_PATCH_PENDING))
+ task->patch_state = READ_ONCE(klp_target_state);
+
+ rcu_read_unlock();
+}
+
+/*
+ * Initialize the global target patch state and all tasks to the initial patch
+ * state, and initialize all function transition states to true in preparation
+ * for patching or unpatching.
+ */
+void klp_init_transition(struct klp_patch *patch, int state)
+{
+ struct task_struct *g, *task;
+ unsigned int cpu;
+ struct klp_object *obj;
+ struct klp_func *func;
+ int initial_state = !state;
+
+ WARN_ON_ONCE(klp_target_state != KLP_UNDEFINED);
+
+ klp_transition_patch = patch;
+
+ /*
+ * Set the global target patch state which tasks will switch to. This
+ * has no effect until the TIF_PATCH_PENDING flags get set later.
+ */
+ klp_target_state = state;
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (patch->immediate)
+ return;
+
+ /*
+ * Initialize all tasks to the initial patch state to prepare them for
+ * switching to the target state.
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task) {
+ WARN_ON_ONCE(task->patch_state != KLP_UNDEFINED);
+ task->patch_state = initial_state;
+ }
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks.
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu) {
+ task = idle_task(cpu);
+ WARN_ON_ONCE(task->patch_state != KLP_UNDEFINED);
+ task->patch_state = initial_state;
+ }
+ put_online_cpus();
We allow to add/remove CPUs here. I am afraid that we will also need
to add a cpu coming/going handler that will set the task->patch_state
the right way. We must not set the klp_target_state until all ftrace
handlers are ready.
What if we instead just change the above to use for_each_possible_cpu()?
We could do the same in klp_complete_transition().
quoted
+ /*
+ * Enforce the order of the task->patch_state initializations and the
+ * func->transition updates to ensure that, in the enable path,
+ * klp_ftrace_handler() doesn't see a func in transition with a
+ * task->patch_state of KLP_UNDEFINED.
+ */
+ smp_wmb();
+
+ /*
+ * Set the func transition states so klp_ftrace_handler() will know to
+ * switch to the transition logic.
+ *
+ * When patching, the funcs aren't yet in the func_stack and will be
+ * made visible to the ftrace handler shortly by the calls to
+ * klp_patch_object().
+ *
+ * When unpatching, the funcs are already in the func_stack and so are
+ * already visible to the ftrace handler.
+ */
+ klp_for_each_object(patch, obj)
+ klp_for_each_func(obj, func)
+ func->transition = true;
+}
+
+/*
+ * Start the transition to the specified target patch state so tasks can begin
+ * switching to it.
+ */
+void klp_start_transition(void)
+{
+ struct task_struct *g, *task;
+ unsigned int cpu;
+
+ WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
+
+ pr_notice("'%s': %s...\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (klp_transition_patch->immediate)
+ return;
+
+ /*
+ * Mark all normal tasks as needing a patch state update. As they pass
+ * through the syscall barrier they'll switch over to the target state
+ * (unless we switch them in klp_try_complete_transition() first).
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task)
+ set_tsk_thread_flag(task, TIF_PATCH_PENDING);
This is called also from klp_reverse_transition(). We should set it
only when the task need migration. Also we should clear it when
the task is in the right state already.
It is not only optimization. It actually solves a race between
klp_complete_transition() and klp_update_patch_state(), see below.
I agree about the race, but if I did:
for_each_process_thread(g, task) {
if (task->patch_state != klp_target_state)
set_tsk_thread_flag(task, TIF_PATCH_PENDING);
else
clear_tsk_thread_flag(task, TIF_PATCH_PENDING);
}
It would still leave a small window where TIF_PATCH_PENDING gets set for
an already patched task, if klp_update_patch_state() is running at the
same time.
See below for another solution.
quoted
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks, though they never cross the
+ * syscall barrier. Instead they switch over in cpu_idle_loop().
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu)
+ set_tsk_thread_flag(idle_task(cpu), TIF_PATCH_PENDING);
+ put_online_cpus();
Also this stage need to be somehow handled by CPU coming/going
handlers.
Here I think we could automatically switch any offline CPUs' idle tasks.
And something similar in klp_try_complete_transition().
quoted
+}
+
+/*
+ * The transition to the target patch state is complete. Clean up the data
+ * structures.
+ */
+void klp_complete_transition(void)
+{
+ struct klp_object *obj;
+ struct klp_func *func;
+ struct task_struct *g, *task;
+ unsigned int cpu;
+
+ if (klp_transition_patch->immediate)
+ goto done;
+
+ klp_for_each_object(klp_transition_patch, obj)
+ klp_for_each_func(obj, func)
+ func->transition = false;
We should call rcu_synchronize() here. Otherwise, there
might be a race, see below:
CPU1 CPU2
klp_ftrace_handler()
if (unlikely(func->transition))
// still true
klp_complete_transition()
func->transition = false;
task->patch_state =
KLP_UNDEFINED;
patch_state = current->patch_state;
WARN_ON(patch_state == KLP_UNDEFINED);
BANG!: We print the warning.
This shouldn't be possible because klp_try_complete_transition() calls
rcu_synchronize() before calling klp_complete_transition(). So by the
time klp_complete_transition() is called, the ftrace handler can no
longer see the affected func. See the comment for rcu_synchronize() in
klp_try_complete_transition().
Note that that smp_wmb() is enough in klp_init_transition()
but it is not enough here. We need to wait longer once
someone might be inside the if (true) code.
If TIF_PATCH_PENDING flag is set here it means that
klp_update_patch_state() might get triggered and it might
put wrong value into task->patch_state.
We must make sure that all task have this cleared before
calling this function. This is another reason why
klp_init_transition() should set the flag only when
transition is needed.
We should only check the state here.
It still might make sense to clear it when it is set wrongly.
But the question is if it is really safe to continue. I am
afraid that it is not. It would mean that the consistency
model is broken and we are in strange state.
As I mentioned above, with your proposal I think there could still be a
task with a spurious set TIF_PATCH_PENDING at this point.
Maybe instead we should clear all the TIF_PATCH_PENDING flags before the
synchronize_rcu() in klp_try_complete_transition().
+
+/*
+ * Try to switch all remaining tasks to the target patch state by walking the
+ * stacks of sleeping tasks and looking for any to-be-patched or
+ * to-be-unpatched functions. If such functions are found, the task can't be
+ * switched yet.
+ *
+ * If any tasks are still stuck in the initial patch state, schedule a retry.
+ */
+bool klp_try_complete_transition(void)
+{
+ unsigned int cpu;
+ struct task_struct *g, *task;
+ bool complete = true;
+
+ WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (klp_transition_patch->immediate)
+ goto success;
+
+ /*
+ * Try to switch the tasks to the target patch state by walking their
+ * stacks and looking for any to-be-patched or to-be-unpatched
+ * functions. If such functions are found on a stack, or if the stack
+ * is deemed unreliable, the task can't be switched yet.
+ *
+ * Usually this will transition most (or all) of the tasks on a system
+ * unless the patch includes changes to a very common function.
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task)
+ if (!klp_try_switch_task(task))
+ complete = false;
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks.
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu)
+ if (!klp_try_switch_task(idle_task(cpu)))
+ complete = false;
+ put_online_cpus();
+
+ /*
+ * Some tasks weren't able to be switched over. Try again later and/or
+ * wait for other methods like syscall barrier switching.
+ */
+ if (!complete)
+ return false;
+
+success:
+
+ /*
+ * When unpatching, all tasks have transitioned to KLP_UNPATCHED so we
+ * can now remove the new functions from the func_stack.
+ */
+ if (klp_target_state == KLP_UNPATCHED)
+ klp_unpatch_objects(klp_transition_patch);
+
+ /*
+ * Wait for all RCU read-side critical sections to complete.
+ *
+ * This has two purposes:
+ *
+ * 1) Ensure all existing critical sections in klp_update_patch_state()
+ * complete, so task->patch_state won't be unexpectedly updated
+ * later.
We should not be here if anyone still might be in klp_update_patch_state().
Depends on our discussion about conditionally setting TIF_PATCH_PENDING.
quoted
+ *
+ * 2) When unpatching, don't allow any existing instances of
+ * klp_ftrace_handler() to access any obsolete funcs before we reset
+ * the func transition states to false. Otherwise the handler may
+ * see the deleted "new" func, see that it's not in transition, and
+ * wrongly pick the new version of the function.
+ */
This makes sense but it too me long time to understand. I wonder if
this might be better:
/*
* Make sure that the function is removed from ops->func_stack
* before we clear func->transition. Otherwise the handler may
* pick the wrong version.
*/
Sounds good.
And I would call this only when the patch is being removed
if (klp_target_state = KLP_UNPATCHED)
synchronize_rcu();
Depends on our discussion about conditionally setting TIF_PATCH_PENDING.
I think that this was the reason to remove WARN_ON_ONCE(!func)
in klp_ftrace_handler(). But this is not related. If this was
the last entry in the list, we removed the ftrace_handler
before removing the last entry. And unregister_ftrace_function()
calls rcu_synchronize() to prevent calling the handler later.
quoted
+ synchronize_rcu();
+
+ pr_notice("'%s': %s complete\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
+ /* we're done, now cleanup the data structures */
+ klp_complete_transition();
+
+ return true;
+}
+
+/*
+ * This function can be called in the middle of an existing transition to
+ * reverse the direction of the target patch state. This can be done to
+ * effectively cancel an existing enable or disable operation if there are any
+ * tasks which are stuck in the initial patch state.
+ */
+void klp_reverse_transition(void)
+{
+ klp_transition_patch->enabled = !klp_transition_patch->enabled;
+
+ klp_target_state = !klp_target_state;
+
+ /*
+ * Enforce the order of the write to klp_target_state above and the
+ * TIF_PATCH_PENDING writes in klp_start_transition() to ensure that
+ * klp_update_patch_state() doesn't set a wrong task->patch_state.
+ */
+ smp_wmb();
I would call rcu_synchronize() here to make sure that
klp_update_patch_state() calls will not set
an outdated task->patch_state.
Note that smp_wmb() is not enough. We do not check TIF_PATCH_PENDING
in klp_try_switch_task(). There is a tiny race:
CPU1 CPU2
klp_update_patch_state()
if (test_and clear(task, TIF)
READ_ONCE(klp_target_state);
mutex_lock(klp_lock);
klp_reverse_transition()
klp_target_state =
!klp_target_state;
klp_start_transition()
mutex_unlock(klp_lock);
<switch to another process>
klp_transition_work_fn()
mutex_lock(klp_lock);
klp_try_complete_transition()
klp_try_switch_task()
if (task->patch_state ==
klp_target_state)
return true;
task->patch_state = <outdated_value>;
klp_ftrace_handler()
BANG: klp_ftrace_handler() will use wrong implementation according
to the outdated task->patch_state. At the same time,
klp_transition() is not blocked by the task because it thinks
that it has a correct state.
@@ -69,6 +71,11 @@ static int livepatch_init(void){intret;+if(!klp_have_reliable_stack()&&!patch.immediate){+pr_notice("disabling consistency model!\n");+patch.immediate=true;+}
I am scared to have this in the sample module. It makes sense
to use the consistency model even for immediate patches because
it allows to remove them. But this must not be used for patches
that really require the consistency model. We should add
a big fat warning at least.
I did this so that the sample module would still work for non-x86_64
arches, for which there's currently no way to patch kthreads.
Notice I did add a warning:
pr_notice("disabling consistency model!\n");
Is the warning not fat enough?
quoted
+
ret = klp_register_patch(&patch);
if (ret)
return ret;
I like the patch. All the problems that I found look solvable.
I think that we are on the right way.
From: Petr Mladek <pmladek@suse.com> Date: 2016-12-22 14:35:02
On Wed 2016-12-21 15:25:05, Josh Poimboeuf wrote:
On Tue, Dec 20, 2016 at 06:32:46PM +0100, Petr Mladek wrote:
quoted
On Thu 2016-12-08 12:08:38, Josh Poimboeuf wrote:
quoted
Change livepatch to use a basic per-task consistency model. This is the
foundation which will eventually enable us to patch those ~10% of
security patches which change function or data semantics. This is the
biggest remaining piece needed to make livepatch more generally useful.
[1] https://lkml.kernel.org/r/20141107140458.GA21774@suse.cz
--- /dev/null+++ b/kernel/livepatch/transition.c
+/*
+ * Initialize the global target patch state and all tasks to the initial patch
+ * state, and initialize all function transition states to true in preparation
+ * for patching or unpatching.
+ */
+void klp_init_transition(struct klp_patch *patch, int state)
+{
+ struct task_struct *g, *task;
+ unsigned int cpu;
+ struct klp_object *obj;
+ struct klp_func *func;
+ int initial_state = !state;
+
+ WARN_ON_ONCE(klp_target_state != KLP_UNDEFINED);
+
+ klp_transition_patch = patch;
+
+ /*
+ * Set the global target patch state which tasks will switch to. This
+ * has no effect until the TIF_PATCH_PENDING flags get set later.
+ */
+ klp_target_state = state;
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (patch->immediate)
+ return;
+
+ /*
+ * Initialize all tasks to the initial patch state to prepare them for
+ * switching to the target state.
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task) {
+ WARN_ON_ONCE(task->patch_state != KLP_UNDEFINED);
+ task->patch_state = initial_state;
+ }
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks.
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu) {
+ task = idle_task(cpu);
+ WARN_ON_ONCE(task->patch_state != KLP_UNDEFINED);
+ task->patch_state = initial_state;
+ }
+ put_online_cpus();
We allow to add/remove CPUs here. I am afraid that we will also need
to add a cpu coming/going handler that will set the task->patch_state
the right way. We must not set the klp_target_state until all ftrace
handlers are ready.
What if we instead just change the above to use for_each_possible_cpu()?
We could do the same in klp_complete_transition().
I like this idea. It seems that there is idle task for each possible
cpu, see idle_threads_init().
IMHO, we should do the same everytime we do anything with the idle
tasks. I mean in klp_start_transition, klp_try_complete_transition()
and also complete_transition().
Then they will be handled like any other processes and we do not need
to think of any special races.
quoted
quoted
+ /*
+ * Enforce the order of the task->patch_state initializations and the
+ * func->transition updates to ensure that, in the enable path,
+ * klp_ftrace_handler() doesn't see a func in transition with a
+ * task->patch_state of KLP_UNDEFINED.
+ */
+ smp_wmb();
+
+ /*
+ * Set the func transition states so klp_ftrace_handler() will know to
+ * switch to the transition logic.
+ *
+ * When patching, the funcs aren't yet in the func_stack and will be
+ * made visible to the ftrace handler shortly by the calls to
+ * klp_patch_object().
+ *
+ * When unpatching, the funcs are already in the func_stack and so are
+ * already visible to the ftrace handler.
+ */
+ klp_for_each_object(patch, obj)
+ klp_for_each_func(obj, func)
+ func->transition = true;
+}
+
+/*
+ * Start the transition to the specified target patch state so tasks can begin
+ * switching to it.
+ */
+void klp_start_transition(void)
+{
+ struct task_struct *g, *task;
+ unsigned int cpu;
+
+ WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
+
+ pr_notice("'%s': %s...\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (klp_transition_patch->immediate)
+ return;
+
+ /*
+ * Mark all normal tasks as needing a patch state update. As they pass
+ * through the syscall barrier they'll switch over to the target state
+ * (unless we switch them in klp_try_complete_transition() first).
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task)
+ set_tsk_thread_flag(task, TIF_PATCH_PENDING);
This is called also from klp_reverse_transition(). We should set it
only when the task need migration. Also we should clear it when
the task is in the right state already.
It is not only optimization. It actually solves a race between
klp_complete_transition() and klp_update_patch_state(), see below.
I agree about the race, but if I did:
for_each_process_thread(g, task) {
if (task->patch_state != klp_target_state)
set_tsk_thread_flag(task, TIF_PATCH_PENDING);
else
clear_tsk_thread_flag(task, TIF_PATCH_PENDING);
}
It would still leave a small window where TIF_PATCH_PENDING gets set for
an already patched task, if klp_update_patch_state() is running at the
same time.
I see your point. Well, it seems that it is more complicated:
The race would be possible only when this was called from
klp_reverse_transition(). But we need to call there
rcu_synchronize() to prevent races with klp_update_patch_state()
also to prevent prelimitary patch completion.
The result is:
if (task->patch_state != klp_target_state) {
# it means that the task was already migrated before
# we reverted klp_target_state. It means that
# the TIF flag was already cleared, the related
# klp_update_patch_state() already finished (thanks
# to rcu_synchronize() and new one will be called
# only when we set the flag again
# => it is safe to set it
# we should also check and warn when the TIF flag
# was not clear before we set it here
else
# the task was not migrated before we reverted
# klp_target_state. klp_update_patch_state()
# could run in parallel but it will do the same
# what we do, clear TIF flag and keep the patch_state
# as is
# => it is safe to clear it
I agree that this is complex like hell. But it also allows use to
check that things work as we expect.
If we always set the flag here and always clear it later, we might
hide a bug.
If we want to make it slightly more straightforward, we might
clear TIF flags in klp_reverse_transaction() before we revert
klp_target_state. The later rcu_synchronize() should make sure
that all migrations are finished and non-will run in parallel.
Then we could set the TIF flag only where needed here.
quoted
quoted
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks, though they never cross the
+ * syscall barrier. Instead they switch over in cpu_idle_loop().
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu)
+ set_tsk_thread_flag(idle_task(cpu), TIF_PATCH_PENDING);
+ put_online_cpus();
Also this stage need to be somehow handled by CPU coming/going
handlers.
Here I think we could automatically switch any offline CPUs' idle tasks.
And something similar in klp_try_complete_transition().
We still need to make sure to do not race with the cpu_up()/cpu_down()
calls.
I would use here the trick with for_each_possible_cpu() and let
the migration for the stack check.
quoted
quoted
+}
+
+/*
+ * The transition to the target patch state is complete. Clean up the data
+ * structures.
+ */
+void klp_complete_transition(void)
+{
+ struct klp_object *obj;
+ struct klp_func *func;
+ struct task_struct *g, *task;
+ unsigned int cpu;
+
+ if (klp_transition_patch->immediate)
+ goto done;
+
+ klp_for_each_object(klp_transition_patch, obj)
+ klp_for_each_func(obj, func)
+ func->transition = false;
We should call rcu_synchronize() here. Otherwise, there
might be a race, see below:
CPU1 CPU2
klp_ftrace_handler()
if (unlikely(func->transition))
// still true
klp_complete_transition()
func->transition = false;
task->patch_state =
KLP_UNDEFINED;
patch_state = current->patch_state;
WARN_ON(patch_state == KLP_UNDEFINED);
BANG!: We print the warning.
This shouldn't be possible because klp_try_complete_transition() calls
rcu_synchronize() before calling klp_complete_transition(). So by the
time klp_complete_transition() is called, the ftrace handler can no
longer see the affected func. See the comment for rcu_synchronize() in
klp_try_complete_transition().
But rcu_synchronize() in klp_try_complete_transition() will help only
when the patch is being disabled. The ftrace handler will still see
this function and race when the patch is being enabled.
But you are partially right. We need the rcu_synchronize() here
only when the patch is being enabled. It actually matches my comments
in klp_try_complete_transition() where I suggested to call it
only when the patch is being removed.
quoted
Note that that smp_wmb() is enough in klp_init_transition()
but it is not enough here. We need to wait longer once
someone might be inside the if (true) code.
If TIF_PATCH_PENDING flag is set here it means that
klp_update_patch_state() might get triggered and it might
put wrong value into task->patch_state.
We must make sure that all task have this cleared before
calling this function. This is another reason why
klp_init_transition() should set the flag only when
transition is needed.
We should only check the state here.
It still might make sense to clear it when it is set wrongly.
But the question is if it is really safe to continue. I am
afraid that it is not. It would mean that the consistency
model is broken and we are in strange state.
As I mentioned above, with your proposal I think there could still be a
task with a spurious set TIF_PATCH_PENDING at this point.
I believe that it could not be here if we add that rcu_synchronize()
into klp_reverse_transition().
Maybe instead we should clear all the TIF_PATCH_PENDING flags before the
synchronize_rcu() in klp_try_complete_transition().
It might work. But I believe that we do not need this. If we do it,
we might hide a bug.
+
+/*
+ * Try to switch all remaining tasks to the target patch state by walking the
+ * stacks of sleeping tasks and looking for any to-be-patched or
+ * to-be-unpatched functions. If such functions are found, the task can't be
+ * switched yet.
+ *
+ * If any tasks are still stuck in the initial patch state, schedule a retry.
+ */
+bool klp_try_complete_transition(void)
+{
+ unsigned int cpu;
+ struct task_struct *g, *task;
+ bool complete = true;
+
+ WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (klp_transition_patch->immediate)
+ goto success;
+
+ /*
+ * Try to switch the tasks to the target patch state by walking their
+ * stacks and looking for any to-be-patched or to-be-unpatched
+ * functions. If such functions are found on a stack, or if the stack
+ * is deemed unreliable, the task can't be switched yet.
+ *
+ * Usually this will transition most (or all) of the tasks on a system
+ * unless the patch includes changes to a very common function.
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task)
+ if (!klp_try_switch_task(task))
+ complete = false;
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks.
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu)
+ if (!klp_try_switch_task(idle_task(cpu)))
+ complete = false;
+ put_online_cpus();
+
+ /*
+ * Some tasks weren't able to be switched over. Try again later and/or
+ * wait for other methods like syscall barrier switching.
+ */
+ if (!complete)
+ return false;
+
+success:
+
+ /*
+ * When unpatching, all tasks have transitioned to KLP_UNPATCHED so we
+ * can now remove the new functions from the func_stack.
+ */
+ if (klp_target_state == KLP_UNPATCHED)
+ klp_unpatch_objects(klp_transition_patch);
+
+ /*
+ * Wait for all RCU read-side critical sections to complete.
+ *
+ * This has two purposes:
+ *
+ * 1) Ensure all existing critical sections in klp_update_patch_state()
+ * complete, so task->patch_state won't be unexpectedly updated
+ * later.
We should not be here if anyone still might be in klp_update_patch_state().
Depends on our discussion about conditionally setting TIF_PATCH_PENDING.
Yup.
quoted
quoted
+ *
+ * 2) When unpatching, don't allow any existing instances of
+ * klp_ftrace_handler() to access any obsolete funcs before we reset
+ * the func transition states to false. Otherwise the handler may
+ * see the deleted "new" func, see that it's not in transition, and
+ * wrongly pick the new version of the function.
+ */
This makes sense but it too me long time to understand. I wonder if
this might be better:
/*
* Make sure that the function is removed from ops->func_stack
* before we clear func->transition. Otherwise the handler may
* pick the wrong version.
*/
Sounds good.
quoted
And I would call this only when the patch is being removed
if (klp_target_state = KLP_UNPATCHED)
synchronize_rcu();
Depends on our discussion about conditionally setting TIF_PATCH_PENDING.
And yup.
quoted
I think that this was the reason to remove WARN_ON_ONCE(!func)
in klp_ftrace_handler(). But this is not related. If this was
the last entry in the list, we removed the ftrace_handler
before removing the last entry. And unregister_ftrace_function()
calls rcu_synchronize() to prevent calling the handler later.
quoted
+ synchronize_rcu();
+
+ pr_notice("'%s': %s complete\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
+ /* we're done, now cleanup the data structures */
+ klp_complete_transition();
+
+ return true;
+}
+
+/*
+ * This function can be called in the middle of an existing transition to
+ * reverse the direction of the target patch state. This can be done to
+ * effectively cancel an existing enable or disable operation if there are any
+ * tasks which are stuck in the initial patch state.
+ */
+void klp_reverse_transition(void)
+{
+ klp_transition_patch->enabled = !klp_transition_patch->enabled;
+
+ klp_target_state = !klp_target_state;
+
+ /*
+ * Enforce the order of the write to klp_target_state above and the
+ * TIF_PATCH_PENDING writes in klp_start_transition() to ensure that
+ * klp_update_patch_state() doesn't set a wrong task->patch_state.
+ */
+ smp_wmb();
I would call rcu_synchronize() here to make sure that
klp_update_patch_state() calls will not set
an outdated task->patch_state.
Note that smp_wmb() is not enough. We do not check TIF_PATCH_PENDING
in klp_try_switch_task(). There is a tiny race:
CPU1 CPU2
klp_update_patch_state()
if (test_and clear(task, TIF)
READ_ONCE(klp_target_state);
mutex_lock(klp_lock);
klp_reverse_transition()
klp_target_state =
!klp_target_state;
klp_start_transition()
mutex_unlock(klp_lock);
<switch to another process>
klp_transition_work_fn()
mutex_lock(klp_lock);
klp_try_complete_transition()
klp_try_switch_task()
if (task->patch_state ==
klp_target_state)
return true;
task->patch_state = <outdated_value>;
klp_ftrace_handler()
BANG: klp_ftrace_handler() will use wrong implementation according
to the outdated task->patch_state. At the same time,
klp_transition() is not blocked by the task because it thinks
that it has a correct state.
@@ -69,6 +71,11 @@ static int livepatch_init(void){intret;+if(!klp_have_reliable_stack()&&!patch.immediate){+pr_notice("disabling consistency model!\n");+patch.immediate=true;+}
I am scared to have this in the sample module. It makes sense
to use the consistency model even for immediate patches because
it allows to remove them. But this must not be used for patches
that really require the consistency model. We should add
a big fat warning at least.
I did this so that the sample module would still work for non-x86_64
arches, for which there's currently no way to patch kthreads.
Notice I did add a warning:
pr_notice("disabling consistency model!\n");
Is the warning not fat enough?
The warning does not explain who did it, why, if it is safe, and when
this could be used. I suggest a comment like:
/*
* WARNING: Use this check only when you know what you do!
*
* This sample patch does not change the semantic of the data structures,
* locks, or return adresses. It is safe to be applied immediately.
* But we want to test and use the consistency model on supported
* architectures. It allows to remove the patch module.
*
* See Documentation/livepatch/livepatch.txt for more details, please.
*/
Also the message might be more explicit.
pr_notice("livepatch-sample: The consistency model is not supported on
this architecture. Using the immediate model that is safe enough.\n");
Alternatively, we might allow more values for patch.immediate, e.g.
enum klp_consistency_model {
KLP_CM_IMMEDIATE,
KLP_CM_TASK,
KLP_CM_TASK_OR_IMMEDIATE,
};
Then we could do the decision on the kernel side.
But I am not sure if this would be widely used and it
it is worth the complication.
Best Regards,
Petr
PS: Merry Christmas and happy new year!
I am not sure if I will be able to do another deep dive into
this code until next year.
On Thu, Dec 22, 2016 at 03:34:52PM +0100, Petr Mladek wrote:
On Wed 2016-12-21 15:25:05, Josh Poimboeuf wrote:
quoted
On Tue, Dec 20, 2016 at 06:32:46PM +0100, Petr Mladek wrote:
quoted
On Thu 2016-12-08 12:08:38, Josh Poimboeuf wrote:
quoted
Change livepatch to use a basic per-task consistency model. This is the
foundation which will eventually enable us to patch those ~10% of
security patches which change function or data semantics. This is the
biggest remaining piece needed to make livepatch more generally useful.
[1] https://lkml.kernel.org/r/20141107140458.GA21774@suse.cz
--- /dev/null+++ b/kernel/livepatch/transition.c
+/*
+ * Initialize the global target patch state and all tasks to the initial patch
+ * state, and initialize all function transition states to true in preparation
+ * for patching or unpatching.
+ */
+void klp_init_transition(struct klp_patch *patch, int state)
+{
+ struct task_struct *g, *task;
+ unsigned int cpu;
+ struct klp_object *obj;
+ struct klp_func *func;
+ int initial_state = !state;
+
+ WARN_ON_ONCE(klp_target_state != KLP_UNDEFINED);
+
+ klp_transition_patch = patch;
+
+ /*
+ * Set the global target patch state which tasks will switch to. This
+ * has no effect until the TIF_PATCH_PENDING flags get set later.
+ */
+ klp_target_state = state;
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (patch->immediate)
+ return;
+
+ /*
+ * Initialize all tasks to the initial patch state to prepare them for
+ * switching to the target state.
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task) {
+ WARN_ON_ONCE(task->patch_state != KLP_UNDEFINED);
+ task->patch_state = initial_state;
+ }
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks.
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu) {
+ task = idle_task(cpu);
+ WARN_ON_ONCE(task->patch_state != KLP_UNDEFINED);
+ task->patch_state = initial_state;
+ }
+ put_online_cpus();
We allow to add/remove CPUs here. I am afraid that we will also need
to add a cpu coming/going handler that will set the task->patch_state
the right way. We must not set the klp_target_state until all ftrace
handlers are ready.
What if we instead just change the above to use for_each_possible_cpu()?
We could do the same in klp_complete_transition().
I like this idea. It seems that there is idle task for each possible
cpu, see idle_threads_init().
IMHO, we should do the same everytime we do anything with the idle
tasks. I mean in klp_start_transition, klp_try_complete_transition()
and also complete_transition().
Then they will be handled like any other processes and we do not need
to think of any special races.
More on this below.
quoted
quoted
quoted
+ /*
+ * Enforce the order of the task->patch_state initializations and the
+ * func->transition updates to ensure that, in the enable path,
+ * klp_ftrace_handler() doesn't see a func in transition with a
+ * task->patch_state of KLP_UNDEFINED.
+ */
+ smp_wmb();
+
+ /*
+ * Set the func transition states so klp_ftrace_handler() will know to
+ * switch to the transition logic.
+ *
+ * When patching, the funcs aren't yet in the func_stack and will be
+ * made visible to the ftrace handler shortly by the calls to
+ * klp_patch_object().
+ *
+ * When unpatching, the funcs are already in the func_stack and so are
+ * already visible to the ftrace handler.
+ */
+ klp_for_each_object(patch, obj)
+ klp_for_each_func(obj, func)
+ func->transition = true;
+}
+
+/*
+ * Start the transition to the specified target patch state so tasks can begin
+ * switching to it.
+ */
+void klp_start_transition(void)
+{
+ struct task_struct *g, *task;
+ unsigned int cpu;
+
+ WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
+
+ pr_notice("'%s': %s...\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (klp_transition_patch->immediate)
+ return;
+
+ /*
+ * Mark all normal tasks as needing a patch state update. As they pass
+ * through the syscall barrier they'll switch over to the target state
+ * (unless we switch them in klp_try_complete_transition() first).
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task)
+ set_tsk_thread_flag(task, TIF_PATCH_PENDING);
This is called also from klp_reverse_transition(). We should set it
only when the task need migration. Also we should clear it when
the task is in the right state already.
It is not only optimization. It actually solves a race between
klp_complete_transition() and klp_update_patch_state(), see below.
I agree about the race, but if I did:
for_each_process_thread(g, task) {
if (task->patch_state != klp_target_state)
set_tsk_thread_flag(task, TIF_PATCH_PENDING);
else
clear_tsk_thread_flag(task, TIF_PATCH_PENDING);
}
It would still leave a small window where TIF_PATCH_PENDING gets set for
an already patched task, if klp_update_patch_state() is running at the
same time.
I see your point. Well, it seems that it is more complicated:
The race would be possible only when this was called from
klp_reverse_transition(). But we need to call there
rcu_synchronize() to prevent races with klp_update_patch_state()
also to prevent prelimitary patch completion.
The result is:
if (task->patch_state != klp_target_state) {
# it means that the task was already migrated before
# we reverted klp_target_state. It means that
# the TIF flag was already cleared, the related
# klp_update_patch_state() already finished (thanks
# to rcu_synchronize() and new one will be called
# only when we set the flag again
# => it is safe to set it
# we should also check and warn when the TIF flag
# was not clear before we set it here
else
# the task was not migrated before we reverted
# klp_target_state. klp_update_patch_state()
# could run in parallel but it will do the same
# what we do, clear TIF flag and keep the patch_state
# as is
# => it is safe to clear it
I agree that this is complex like hell. But it also allows use to
check that things work as we expect.
Ouch. I agree that it seems safe but it's way too hard to reason about.
And then it gets worse if you try to think about what happens when
adding another reverse operation.
If we always set the flag here and always clear it later, we might
hide a bug.
If we want to make it slightly more straightforward, we might
clear TIF flags in klp_reverse_transaction() before we revert
klp_target_state. The later rcu_synchronize() should make sure
that all migrations are finished and non-will run in parallel.
Then we could set the TIF flag only where needed here.
I think this last paragraph is important. It would simplify things
greatly and ensure we won't have klp_update_patch_state() changing
things in the background.
quoted
quoted
quoted
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks, though they never cross the
+ * syscall barrier. Instead they switch over in cpu_idle_loop().
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu)
+ set_tsk_thread_flag(idle_task(cpu), TIF_PATCH_PENDING);
+ put_online_cpus();
Also this stage need to be somehow handled by CPU coming/going
handlers.
Here I think we could automatically switch any offline CPUs' idle tasks.
And something similar in klp_try_complete_transition().
We still need to make sure to do not race with the cpu_up()/cpu_down()
calls.
Hm, maybe we'd need to call cpu_hotplug_disable() before switching the
offline idle tasks?
I would use here the trick with for_each_possible_cpu() and let
the migration for the stack check.
There are a few issues with that:
1) The idle task of a missing CPU doesn't *have* a stack, so it doesn't
make much sense to try to check it.
2) We can't rely *only* on the stack check, because not all arches have
it. The other way to migrate idle tasks is from the idle loop switch
point. But if the task's CPU is down, its idle loop isn't running so
it can't migrate.
(Note this is currently a theoretical point: we currently don't allow
such arches to use the consistency model anyway because there's no
way for them to migrate kthreads.)
quoted
quoted
quoted
+}
+
+/*
+ * The transition to the target patch state is complete. Clean up the data
+ * structures.
+ */
+void klp_complete_transition(void)
+{
+ struct klp_object *obj;
+ struct klp_func *func;
+ struct task_struct *g, *task;
+ unsigned int cpu;
+
+ if (klp_transition_patch->immediate)
+ goto done;
+
+ klp_for_each_object(klp_transition_patch, obj)
+ klp_for_each_func(obj, func)
+ func->transition = false;
We should call rcu_synchronize() here. Otherwise, there
might be a race, see below:
CPU1 CPU2
klp_ftrace_handler()
if (unlikely(func->transition))
// still true
klp_complete_transition()
func->transition = false;
task->patch_state =
KLP_UNDEFINED;
patch_state = current->patch_state;
WARN_ON(patch_state == KLP_UNDEFINED);
BANG!: We print the warning.
This shouldn't be possible because klp_try_complete_transition() calls
rcu_synchronize() before calling klp_complete_transition(). So by the
time klp_complete_transition() is called, the ftrace handler can no
longer see the affected func. See the comment for rcu_synchronize() in
klp_try_complete_transition().
But rcu_synchronize() in klp_try_complete_transition() will help only
when the patch is being disabled. The ftrace handler will still see
this function and race when the patch is being enabled.
But you are partially right. We need the rcu_synchronize() here
only when the patch is being enabled. It actually matches my comments
in klp_try_complete_transition() where I suggested to call it
only when the patch is being removed.
Sorry, for some reason I think I saw KLP_UNPATCHED in your example
instead of KLP_UNDEFINED. I get it now.
quoted
quoted
Note that that smp_wmb() is enough in klp_init_transition()
but it is not enough here. We need to wait longer once
someone might be inside the if (true) code.
If TIF_PATCH_PENDING flag is set here it means that
klp_update_patch_state() might get triggered and it might
put wrong value into task->patch_state.
We must make sure that all task have this cleared before
calling this function. This is another reason why
klp_init_transition() should set the flag only when
transition is needed.
We should only check the state here.
It still might make sense to clear it when it is set wrongly.
But the question is if it is really safe to continue. I am
afraid that it is not. It would mean that the consistency
model is broken and we are in strange state.
As I mentioned above, with your proposal I think there could still be a
task with a spurious set TIF_PATCH_PENDING at this point.
I believe that it could not be here if we add that rcu_synchronize()
into klp_reverse_transition().
quoted
Maybe instead we should clear all the TIF_PATCH_PENDING flags before the
synchronize_rcu() in klp_try_complete_transition().
It might work. But I believe that we do not need this. If we do it,
we might hide a bug.
+
+/*
+ * Try to switch all remaining tasks to the target patch state by walking the
+ * stacks of sleeping tasks and looking for any to-be-patched or
+ * to-be-unpatched functions. If such functions are found, the task can't be
+ * switched yet.
+ *
+ * If any tasks are still stuck in the initial patch state, schedule a retry.
+ */
+bool klp_try_complete_transition(void)
+{
+ unsigned int cpu;
+ struct task_struct *g, *task;
+ bool complete = true;
+
+ WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (klp_transition_patch->immediate)
+ goto success;
+
+ /*
+ * Try to switch the tasks to the target patch state by walking their
+ * stacks and looking for any to-be-patched or to-be-unpatched
+ * functions. If such functions are found on a stack, or if the stack
+ * is deemed unreliable, the task can't be switched yet.
+ *
+ * Usually this will transition most (or all) of the tasks on a system
+ * unless the patch includes changes to a very common function.
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task)
+ if (!klp_try_switch_task(task))
+ complete = false;
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks.
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu)
+ if (!klp_try_switch_task(idle_task(cpu)))
+ complete = false;
+ put_online_cpus();
+
+ /*
+ * Some tasks weren't able to be switched over. Try again later and/or
+ * wait for other methods like syscall barrier switching.
+ */
+ if (!complete)
+ return false;
+
+success:
+
+ /*
+ * When unpatching, all tasks have transitioned to KLP_UNPATCHED so we
+ * can now remove the new functions from the func_stack.
+ */
+ if (klp_target_state == KLP_UNPATCHED)
+ klp_unpatch_objects(klp_transition_patch);
+
+ /*
+ * Wait for all RCU read-side critical sections to complete.
+ *
+ * This has two purposes:
+ *
+ * 1) Ensure all existing critical sections in klp_update_patch_state()
+ * complete, so task->patch_state won't be unexpectedly updated
+ * later.
We should not be here if anyone still might be in klp_update_patch_state().
Depends on our discussion about conditionally setting TIF_PATCH_PENDING.
Yup.
quoted
quoted
quoted
+ *
+ * 2) When unpatching, don't allow any existing instances of
+ * klp_ftrace_handler() to access any obsolete funcs before we reset
+ * the func transition states to false. Otherwise the handler may
+ * see the deleted "new" func, see that it's not in transition, and
+ * wrongly pick the new version of the function.
+ */
This makes sense but it too me long time to understand. I wonder if
this might be better:
/*
* Make sure that the function is removed from ops->func_stack
* before we clear func->transition. Otherwise the handler may
* pick the wrong version.
*/
Sounds good.
quoted
And I would call this only when the patch is being removed
if (klp_target_state = KLP_UNPATCHED)
synchronize_rcu();
Depends on our discussion about conditionally setting TIF_PATCH_PENDING.
And yup.
quoted
quoted
I think that this was the reason to remove WARN_ON_ONCE(!func)
in klp_ftrace_handler(). But this is not related. If this was
the last entry in the list, we removed the ftrace_handler
before removing the last entry. And unregister_ftrace_function()
calls rcu_synchronize() to prevent calling the handler later.
quoted
+ synchronize_rcu();
+
+ pr_notice("'%s': %s complete\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
+ /* we're done, now cleanup the data structures */
+ klp_complete_transition();
+
+ return true;
+}
+
+/*
+ * This function can be called in the middle of an existing transition to
+ * reverse the direction of the target patch state. This can be done to
+ * effectively cancel an existing enable or disable operation if there are any
+ * tasks which are stuck in the initial patch state.
+ */
+void klp_reverse_transition(void)
+{
+ klp_transition_patch->enabled = !klp_transition_patch->enabled;
+
+ klp_target_state = !klp_target_state;
+
+ /*
+ * Enforce the order of the write to klp_target_state above and the
+ * TIF_PATCH_PENDING writes in klp_start_transition() to ensure that
+ * klp_update_patch_state() doesn't set a wrong task->patch_state.
+ */
+ smp_wmb();
I would call rcu_synchronize() here to make sure that
klp_update_patch_state() calls will not set
an outdated task->patch_state.
Note that smp_wmb() is not enough. We do not check TIF_PATCH_PENDING
in klp_try_switch_task(). There is a tiny race:
CPU1 CPU2
klp_update_patch_state()
if (test_and clear(task, TIF)
READ_ONCE(klp_target_state);
mutex_lock(klp_lock);
klp_reverse_transition()
klp_target_state =
!klp_target_state;
klp_start_transition()
mutex_unlock(klp_lock);
<switch to another process>
klp_transition_work_fn()
mutex_lock(klp_lock);
klp_try_complete_transition()
klp_try_switch_task()
if (task->patch_state ==
klp_target_state)
return true;
task->patch_state = <outdated_value>;
klp_ftrace_handler()
BANG: klp_ftrace_handler() will use wrong implementation according
to the outdated task->patch_state. At the same time,
klp_transition() is not blocked by the task because it thinks
that it has a correct state.
@@ -69,6 +71,11 @@ static int livepatch_init(void){intret;+if(!klp_have_reliable_stack()&&!patch.immediate){+pr_notice("disabling consistency model!\n");+patch.immediate=true;+}
I am scared to have this in the sample module. It makes sense
to use the consistency model even for immediate patches because
it allows to remove them. But this must not be used for patches
that really require the consistency model. We should add
a big fat warning at least.
I did this so that the sample module would still work for non-x86_64
arches, for which there's currently no way to patch kthreads.
Notice I did add a warning:
pr_notice("disabling consistency model!\n");
Is the warning not fat enough?
The warning does not explain who did it, why, if it is safe, and when
this could be used. I suggest a comment like:
/*
* WARNING: Use this check only when you know what you do!
*
* This sample patch does not change the semantic of the data structures,
* locks, or return adresses. It is safe to be applied immediately.
* But we want to test and use the consistency model on supported
* architectures. It allows to remove the patch module.
*
* See Documentation/livepatch/livepatch.txt for more details, please.
*/
Also the message might be more explicit.
pr_notice("livepatch-sample: The consistency model is not supported on
this architecture. Using the immediate model that is safe enough.\n");
Ok, will try to do something like that.
Alternatively, we might allow more values for patch.immediate, e.g.
enum klp_consistency_model {
KLP_CM_IMMEDIATE,
KLP_CM_TASK,
KLP_CM_TASK_OR_IMMEDIATE,
};
Then we could do the decision on the kernel side.
But I am not sure if this would be widely used and it
it is worth the complication.
I'd rather avoid that :-)
PS: Merry Christmas and happy new year!
I am not sure if I will be able to do another deep dive into
this code until next year.
Same here, I won't be around much until 2017. Cheers!
--
Josh
@@ -54,15 +55,53 @@ static void notrace klp_ftrace_handler(unsigned long ip,{structklp_ops*ops;structklp_func*func;+intpatch_state;ops=container_of(fops,structklp_ops,fops);rcu_read_lock();+func=list_first_or_null_rcu(&ops->func_stack,structklp_func,stack_node);-if(WARN_ON_ONCE(!func))++if(!func)gotounlock;
Why do you removed the WARN_ON_ONCE(), please?
We still add the function on the stack before registering
the ftrace handler. Also we unregister the ftrace handler
before removing the the last entry from the stack.
AFAIK, unregister_ftrace_function() calls rcu_synchronize()'
to make sure that no-one is inside the handler once finished.
Mirek knows more about it.
If this is not true, we have a problem. For example,
we call kfree(ops) after unregister_ftrace_function();
Agreed.
TL;DR - we should be ok as long as we do not do crazy things in the
handler, deliberate sleeping for example.
WARN_ON_ONCE() may be crazy too. I think we discussed it long ago and we
came to an agreement to remove it.
Miroslav, very slowly going through the patch set
@@ -54,15 +55,53 @@ static void notrace klp_ftrace_handler(unsigned long ip,{structklp_ops*ops;structklp_func*func;+intpatch_state;ops=container_of(fops,structklp_ops,fops);rcu_read_lock();+func=list_first_or_null_rcu(&ops->func_stack,structklp_func,stack_node);-if(WARN_ON_ONCE(!func))++if(!func)gotounlock;
Why do you removed the WARN_ON_ONCE(), please?
We still add the function on the stack before registering
the ftrace handler. Also we unregister the ftrace handler
before removing the the last entry from the stack.
AFAIK, unregister_ftrace_function() calls rcu_synchronize()'
to make sure that no-one is inside the handler once finished.
Mirek knows more about it.
If this is not true, we have a problem. For example,
we call kfree(ops) after unregister_ftrace_function();
Agreed.
TL;DR - we should be ok as long as we do not do crazy things in the
handler, deliberate sleeping for example.
WARN_ON_ONCE() may be crazy too. I think we discussed it long ago and we
came to an agreement to remove it.
There are definitely situations where this might hurt. For example,
when we redirect a function called under logbuf_lock.
On the other hand, there is a work in progress[1][2] that will mitigate
this risk a lot. Also this warning would be printed only when
something goes wrong. IMHO, it is worth the risk. It will succeed
in 99,999% cases and it might save us some headache when debugging
random crashes of the system.
Anyway, if there is a reason to remove the warning, it should be
described. And if it is not strictly related to this patch, it should
be handled separately.
[1] https://lkml.kernel.org/r/20161221143605.2272-1-sergey.senozhatsky@gmail.com
[2] https://lkml.kernel.org/r/1461333180-2897-1-git-send-email-sergey.senozhatsky@gmail.com
Best Regards,
Petr
From: Miroslav Benes <mbenes@suse.cz> Date: 2016-12-23 12:58:49
On Thu, 8 Dec 2016, Josh Poimboeuf wrote:
klp_patch_object()'s callers already ensure that the object is loaded,
so its call to klp_is_object_loaded() is unnecessary.
This will also make it possible to move the patching code into a
separate file.
Signed-off-by: Josh Poimboeuf <redacted>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Miroslav
From: Miroslav Benes <mbenes@suse.cz> Date: 2016-12-23 13:13:50
On Fri, 16 Dec 2016, Josh Poimboeuf wrote:
On Fri, Dec 16, 2016 at 05:55:55PM +0100, Petr Mladek wrote:
quoted
On Thu 2016-12-08 12:08:36, Josh Poimboeuf wrote:
quoted
The sysfs enabled value is a boolean, so kstrtobool() is a better fit
for parsing the input string since it does the range checking for us.
Suggested-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Josh Poimboeuf <redacted>
---
kernel/livepatch/core.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
From: Miroslav Benes <mbenes@suse.cz> Date: 2016-12-23 13:13:59
On Thu, 8 Dec 2016, Josh Poimboeuf wrote:
Once we have a consistency model, patches and their objects will be
enabled and disabled at different times. For example, when a patch is
disabled, its loaded objects' funcs can remain registered with ftrace
indefinitely until the unpatching operation is complete and they're no
longer in use.
It's less confusing if we give them different names: patches can be
enabled or disabled; objects (and their funcs) can be patched or
unpatched:
- Enabled means that a patch is logically enabled (but not necessarily
fully applied).
- Patched means that an object's funcs are registered with ftrace and
added to the klp_ops func stack.
Also, since these states are binary, represent them with booleans
instead of ints.
Signed-off-by: Josh Poimboeuf <redacted>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Miroslav
From: Miroslav Benes <mbenes@suse.cz> Date: 2016-12-23 13:40:38
On Thu, 8 Dec 2016, Josh Poimboeuf wrote:
For the consistency model we'll need to know the sizes of the old and
new functions to determine if they're on the stacks of any tasks.
Signed-off-by: Josh Poimboeuf <redacted>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Miroslav
From: Miroslav Benes <mbenes@suse.cz> Date: 2017-01-04 13:44:55
On Thu, 8 Dec 2016, Josh Poimboeuf wrote:
+void klp_start_transition(void)
+{
+ struct task_struct *g, *task;
+ unsigned int cpu;
+
+ WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
+
+ pr_notice("'%s': %s...\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (klp_transition_patch->immediate)
+ return;
+
+ /*
+ * Mark all normal tasks as needing a patch state update. As they pass
+ * through the syscall barrier they'll switch over to the target state
+ * (unless we switch them in klp_try_complete_transition() first).
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task)
+ set_tsk_thread_flag(task, TIF_PATCH_PENDING);
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks, though they never cross the
+ * syscall barrier. Instead they switch over in cpu_idle_loop().
...or we switch them in klp_try_complete_transition() first by looking at
their stacks, right? I would add it to the comment.
I think that (theoretically) this is not sufficient, if we patch a
function present on an idle task's stack and one of the two following
scenarios happen.
1. there is nothing to schedule on a cpu and an idle task does not leave a
loop in do_idle() for some time. It may be a nonsense practically and if
it is not we could solve with schedule_on_each_cpu() on an empty stub
somewhere in our code.
2. there is a cpu-bound process running on one of the cpus. No chance of
going to do_idle() there at all and the idle task would block the
patching. We ran into it in kGraft and I tried to solve it with this new
hunk in pick_next_task()...
+ /*
+ * Patching is in progress, schedule an idle task to migrate it
+ */
+ if (kgr_in_progress_branch()) {
+ if (!test_bit(0, kgr_immutable) &&
+ klp_kgraft_task_in_progress(rq->idle)) {
+ p = idle_sched_class.pick_next_task(rq, prev);
+
+ return p;
+ }
+ }
(kgr_in_progress_branch() is a static key basically. kgr_immutable flag
solves something we don't have a problem with in upstream livepatch thanks
to a combination of task->patch_state and klp_func->transition.
klp_kgraft_task_in_progress() checks the livepatching TIF of a task.)
It is not tested properly and it is a hack as hell so take it as that.
Also note that the problem in kGraft is more serious as we don't have a
stack checking there. So any livepatch could cause the issue easily.
I can imagine even crazier solutions but nothing nice and pretty (which is
probably impossible because the whole idea to deliberately schedule an
idle task is not nice and pretty).
Otherwise the patch looks good to me. I don't understand how Petr found
those races there.
Regards,
Miroslav
From: Miroslav Benes <mbenes@suse.cz> Date: 2017-01-04 14:50:47
On Thu, 8 Dec 2016, Josh Poimboeuf wrote:
Expose the per-task patch state value so users can determine which tasks
are holding up completion of a patching operation.
Signed-off-by: Josh Poimboeuf <redacted>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Miroslav
From: Miroslav Benes <mbenes@suse.cz> Date: 2017-01-05 09:37:47
quoted hunk
@@ -740,6 +809,14 @@ int klp_register_patch(struct klp_patch *patch) return -ENODEV; /*+ * Architectures without reliable stack traces have to set+ * patch->immediate because there's currently no way to patch kthreads+ * with the consistency model.+ */+ if (!klp_have_reliable_stack() && !patch->immediate)+ return -ENOSYS;+
I think an error message (pr_err) would be appropriate here.
$ insmod patch_1.ko
insmod: ERROR: could not insert module patch_1.ko: Function not implemented
is not helpful much :)
Miroslav
@@ -54,15 +55,53 @@ static void notrace klp_ftrace_handler(unsigned long ip,{structklp_ops*ops;structklp_func*func;+intpatch_state;ops=container_of(fops,structklp_ops,fops);rcu_read_lock();+func=list_first_or_null_rcu(&ops->func_stack,structklp_func,stack_node);-if(WARN_ON_ONCE(!func))++if(!func)gotounlock;
Why do you removed the WARN_ON_ONCE(), please?
We still add the function on the stack before registering
the ftrace handler. Also we unregister the ftrace handler
before removing the the last entry from the stack.
AFAIK, unregister_ftrace_function() calls rcu_synchronize()'
to make sure that no-one is inside the handler once finished.
Mirek knows more about it.
If this is not true, we have a problem. For example,
we call kfree(ops) after unregister_ftrace_function();
Agreed.
TL;DR - we should be ok as long as we do not do crazy things in the
handler, deliberate sleeping for example.
WARN_ON_ONCE() may be crazy too. I think we discussed it long ago and we
came to an agreement to remove it.
There are definitely situations where this might hurt. For example,
when we redirect a function called under logbuf_lock.
On the other hand, there is a work in progress[1][2] that will mitigate
this risk a lot. Also this warning would be printed only when
something goes wrong. IMHO, it is worth the risk. It will succeed
in 99,999% cases and it might save us some headache when debugging
random crashes of the system.
Anyway, if there is a reason to remove the warning, it should be
described. And if it is not strictly related to this patch, it should
be handled separately.
[1] https://lkml.kernel.org/r/20161221143605.2272-1-sergey.senozhatsky@gmail.com
[2] https://lkml.kernel.org/r/1461333180-2897-1-git-send-email-sergey.senozhatsky@gmail.com
Yeah, I'm thinking we should keep the warning to catch any bugs in case
any of our ftrace assumptions change. Maybe I should add a comment:
/*
* func can never be NULL because preemption should be disabled
* here and unregister_ftrace_function() does the equivalent of
* a synchronize_sched() before the func_stack removal.
*/
if (WARN_ON_ONCE(!func))
goto unlock;
--
Josh
On Wed, Jan 04, 2017 at 02:44:47PM +0100, Miroslav Benes wrote:
On Thu, 8 Dec 2016, Josh Poimboeuf wrote:
quoted
+void klp_start_transition(void)
+{
+ struct task_struct *g, *task;
+ unsigned int cpu;
+
+ WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
+
+ pr_notice("'%s': %s...\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (klp_transition_patch->immediate)
+ return;
+
+ /*
+ * Mark all normal tasks as needing a patch state update. As they pass
+ * through the syscall barrier they'll switch over to the target state
+ * (unless we switch them in klp_try_complete_transition() first).
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task)
+ set_tsk_thread_flag(task, TIF_PATCH_PENDING);
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks, though they never cross the
+ * syscall barrier. Instead they switch over in cpu_idle_loop().
...or we switch them in klp_try_complete_transition() first by looking at
their stacks, right? I would add it to the comment.
Yeah, I guess the "ditto" was intended to include the "unless we switch
them in klp_try_complete_transition() first" statement from the previous
comment. I'll try to make it clearer.
I think that (theoretically) this is not sufficient, if we patch a
function present on an idle task's stack and one of the two following
scenarios happen.
Agreed, though I'd argue that these are rare edge cases which can
probably be refined later, outside the scope of this patch set.
1. there is nothing to schedule on a cpu and an idle task does not leave a
loop in do_idle() for some time. It may be a nonsense practically and if
it is not we could solve with schedule_on_each_cpu() on an empty stub
somewhere in our code.
This might only be a theoretical issue, as it only happens when patching
one of the idle functions themselves.
If we decided that this were a real world problem, we could use
something like schedule_on_each_cpu() to flush them out as you
suggested. Or it could even be done from user space by briefly running
a CPU-intensive program on the affected CPUs.
2. there is a cpu-bound process running on one of the cpus. No chance of
going to do_idle() there at all and the idle task would block the
patching.
To clarify I think this would only be an issue when trying to patch idle
code or schedule()/__schedule().
We ran into it in kGraft and I tried to solve it with this new
hunk in pick_next_task()...
+ /*
+ * Patching is in progress, schedule an idle task to migrate it
+ */
+ if (kgr_in_progress_branch()) {
+ if (!test_bit(0, kgr_immutable) &&
+ klp_kgraft_task_in_progress(rq->idle)) {
+ p = idle_sched_class.pick_next_task(rq, prev);
+
+ return p;
+ }
+ }
(kgr_in_progress_branch() is a static key basically. kgr_immutable flag
solves something we don't have a problem with in upstream livepatch thanks
to a combination of task->patch_state and klp_func->transition.
klp_kgraft_task_in_progress() checks the livepatching TIF of a task.)
It is not tested properly and it is a hack as hell so take it as that.
Also note that the problem in kGraft is more serious as we don't have a
stack checking there. So any livepatch could cause the issue easily.
I can imagine even crazier solutions but nothing nice and pretty (which is
probably impossible because the whole idea to deliberately schedule an
idle task is not nice and pretty).
Yeah, that looks hairy...
Since this is such a specialized case (patching the scheduler in an idle
task while CPU-intensive tasks are running) this might also be more
reasonably accomplished from user space by briefly SIGSTOPing the CPU
hog.
Otherwise the patch looks good to me. I don't understand how Petr found
those races there.
On Thu, Jan 05, 2017 at 10:34:57AM +0100, Miroslav Benes wrote:
quoted
@@ -740,6 +809,14 @@ int klp_register_patch(struct klp_patch *patch) return -ENODEV; /*+ * Architectures without reliable stack traces have to set+ * patch->immediate because there's currently no way to patch kthreads+ * with the consistency model.+ */+ if (!klp_have_reliable_stack() && !patch->immediate)+ return -ENOSYS;+
I think an error message (pr_err) would be appropriate here.
$ insmod patch_1.ko
insmod: ERROR: could not insert module patch_1.ko: Function not implemented
is not helpful much :)
On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote:
Add the TIF_PATCH_PENDING thread flag to enable the new livepatch
per-task consistency model for powerpc. The bit getting set indicates
the thread has a pending patch which needs to be applied when the thread
exits the kernel.
The bit is included in the _TIF_USER_WORK_MASK macro so that
do_notify_resume() and klp_update_patch_state() get called when the bit
is set.
Signed-off-by: Josh Poimboeuf <redacted>
On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote:
The _TIF_ALLWORK_MASK macro automatically includes the least-significant
16 bits of the thread_info flags, which is less than obvious and tends
to create confusion and surprises when reading or modifying the code.
Define the flags explicitly.
Signed-off-by: Josh Poimboeuf <redacted>
For the version with swapped _TIF_SINGLESTEP and _TIF_NEED_RESCHED
flags.
Reviewed-by: Kamalesh Babulal <redacted>
--
cheers,
Kamalesh.
On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote:
Once we have a consistency model, patches and their objects will be
enabled and disabled at different times. For example, when a patch is
disabled, its loaded objects' funcs can remain registered with ftrace
indefinitely until the unpatching operation is complete and they're no
longer in use.
It's less confusing if we give them different names: patches can be
enabled or disabled; objects (and their funcs) can be patched or
unpatched:
- Enabled means that a patch is logically enabled (but not necessarily
fully applied).
- Patched means that an object's funcs are registered with ftrace and
added to the klp_ops func stack.
Also, since these states are binary, represent them with booleans
instead of ints.
Signed-off-by: Josh Poimboeuf <redacted>
On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote:
klp_patch_object()'s callers already ensure that the object is loaded,
so its call to klp_is_object_loaded() is unnecessary.
This will also make it possible to move the patching code into a
separate file.
Signed-off-by: Josh Poimboeuf <redacted>
@@ -54,15 +55,53 @@ static void notrace klp_ftrace_handler(unsigned long ip,{structklp_ops*ops;structklp_func*func;+intpatch_state;ops=container_of(fops,structklp_ops,fops);rcu_read_lock();+func=list_first_or_null_rcu(&ops->func_stack,structklp_func,stack_node);-if(WARN_ON_ONCE(!func))++if(!func)gotounlock;
Yeah, I'm thinking we should keep the warning to catch any bugs in case
any of our ftrace assumptions change. Maybe I should add a comment:
/*
* func can never be NULL because preemption should be disabled
* here and unregister_ftrace_function() does the equivalent of
* a synchronize_sched() before the func_stack removal.
*/
if (WARN_ON_ONCE(!func))
goto unlock;
I think that (theoretically) this is not sufficient, if we patch a
function present on an idle task's stack and one of the two following
scenarios happen.
Agreed, though I'd argue that these are rare edge cases which can
probably be refined later, outside the scope of this patch set.
You're right. They should be really rare and we can solve them (if we even
want to) later.
quoted
1. there is nothing to schedule on a cpu and an idle task does not leave a
loop in do_idle() for some time. It may be a nonsense practically and if
it is not we could solve with schedule_on_each_cpu() on an empty stub
somewhere in our code.
This might only be a theoretical issue, as it only happens when patching
one of the idle functions themselves.
If we decided that this were a real world problem, we could use
something like schedule_on_each_cpu() to flush them out as you
suggested. Or it could even be done from user space by briefly running
a CPU-intensive program on the affected CPUs.
Yes.
quoted
2. there is a cpu-bound process running on one of the cpus. No chance of
going to do_idle() there at all and the idle task would block the
patching.
To clarify I think this would only be an issue when trying to patch idle
code or schedule()/__schedule().
Yes.
quoted
We ran into it in kGraft and I tried to solve it with this new
hunk in pick_next_task()...
+ /*
+ * Patching is in progress, schedule an idle task to migrate it
+ */
+ if (kgr_in_progress_branch()) {
+ if (!test_bit(0, kgr_immutable) &&
+ klp_kgraft_task_in_progress(rq->idle)) {
+ p = idle_sched_class.pick_next_task(rq, prev);
+
+ return p;
+ }
+ }
(kgr_in_progress_branch() is a static key basically. kgr_immutable flag
solves something we don't have a problem with in upstream livepatch thanks
to a combination of task->patch_state and klp_func->transition.
klp_kgraft_task_in_progress() checks the livepatching TIF of a task.)
It is not tested properly and it is a hack as hell so take it as that.
Also note that the problem in kGraft is more serious as we don't have a
stack checking there. So any livepatch could cause the issue easily.
I can imagine even crazier solutions but nothing nice and pretty (which is
probably impossible because the whole idea to deliberately schedule an
idle task is not nice and pretty).
Yeah, that looks hairy...
Since this is such a specialized case (patching the scheduler in an idle
task while CPU-intensive tasks are running) this might also be more
reasonably accomplished from user space by briefly SIGSTOPing the CPU
hog.
Yes, that is true. I can imagine there are users who don't want to stop
the cpu hog at all. Even for a fraction of time. HPC comes to mind. But it
is not worth it to solve it with something like the code above. Let's add
it to the very end of our TODO lists :).
Miroslav
From: Petr Mladek <pmladek@suse.com> Date: 2017-01-10 13:01:07
On Thu 2016-12-22 12:31:37, Josh Poimboeuf wrote:
On Thu, Dec 22, 2016 at 03:34:52PM +0100, Petr Mladek wrote:
quoted
On Wed 2016-12-21 15:25:05, Josh Poimboeuf wrote:
quoted
On Tue, Dec 20, 2016 at 06:32:46PM +0100, Petr Mladek wrote:
quoted
On Thu 2016-12-08 12:08:38, Josh Poimboeuf wrote:
quoted
Change livepatch to use a basic per-task consistency model. This is the
foundation which will eventually enable us to patch those ~10% of
security patches which change function or data semantics. This is the
biggest remaining piece needed to make livepatch more generally useful.
[1] https://lkml.kernel.org/r/20141107140458.GA21774@suse.cz
--- /dev/null+++ b/kernel/livepatch/transition.c
+ /*
+ * Enforce the order of the task->patch_state initializations and the
+ * func->transition updates to ensure that, in the enable path,
+ * klp_ftrace_handler() doesn't see a func in transition with a
+ * task->patch_state of KLP_UNDEFINED.
+ */
+ smp_wmb();
+
+ /*
+ * Set the func transition states so klp_ftrace_handler() will know to
+ * switch to the transition logic.
+ *
+ * When patching, the funcs aren't yet in the func_stack and will be
+ * made visible to the ftrace handler shortly by the calls to
+ * klp_patch_object().
+ *
+ * When unpatching, the funcs are already in the func_stack and so are
+ * already visible to the ftrace handler.
+ */
+ klp_for_each_object(patch, obj)
+ klp_for_each_func(obj, func)
+ func->transition = true;
+}
+
+/*
+ * Start the transition to the specified target patch state so tasks can begin
+ * switching to it.
+ */
+void klp_start_transition(void)
+{
+ struct task_struct *g, *task;
+ unsigned int cpu;
+
+ WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
+
+ pr_notice("'%s': %s...\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (klp_transition_patch->immediate)
+ return;
+
+ /*
+ * Mark all normal tasks as needing a patch state update. As they pass
+ * through the syscall barrier they'll switch over to the target state
+ * (unless we switch them in klp_try_complete_transition() first).
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task)
+ set_tsk_thread_flag(task, TIF_PATCH_PENDING);
This is called also from klp_reverse_transition(). We should set it
only when the task need migration. Also we should clear it when
the task is in the right state already.
It is not only optimization. It actually solves a race between
klp_complete_transition() and klp_update_patch_state(), see below.
I agree about the race, but if I did:
for_each_process_thread(g, task) {
if (task->patch_state != klp_target_state)
set_tsk_thread_flag(task, TIF_PATCH_PENDING);
else
clear_tsk_thread_flag(task, TIF_PATCH_PENDING);
}
It would still leave a small window where TIF_PATCH_PENDING gets set for
an already patched task, if klp_update_patch_state() is running at the
same time.
I see your point. Well, it seems that it is more complicated:
The race would be possible only when this was called from
klp_reverse_transition(). But we need to call there
rcu_synchronize() to prevent races with klp_update_patch_state()
also to prevent prelimitary patch completion.
The result is:
if (task->patch_state != klp_target_state) {
# it means that the task was already migrated before
# we reverted klp_target_state. It means that
# the TIF flag was already cleared, the related
# klp_update_patch_state() already finished (thanks
# to rcu_synchronize() and new one will be called
# only when we set the flag again
# => it is safe to set it
# we should also check and warn when the TIF flag
# was not clear before we set it here
else
# the task was not migrated before we reverted
# klp_target_state. klp_update_patch_state()
# could run in parallel but it will do the same
# what we do, clear TIF flag and keep the patch_state
# as is
# => it is safe to clear it
I agree that this is complex like hell. But it also allows use to
check that things work as we expect.
Ouch. I agree that it seems safe but it's way too hard to reason about.
And then it gets worse if you try to think about what happens when
adding another reverse operation.
quoted
If we always set the flag here and always clear it later, we might
hide a bug.
If we want to make it slightly more straightforward, we might
clear TIF flags in klp_reverse_transaction() before we revert
klp_target_state. The later rcu_synchronize() should make sure
that all migrations are finished and non-will run in parallel.
Then we could set the TIF flag only where needed here.
I think this last paragraph is important. It would simplify things
greatly and ensure we won't have klp_update_patch_state() changing
things in the background.
OK, let's clear all TIF_PATCH_PENDIG flags and call rcu_synchronize()
at the beginning of klp_reverse_transition(). It might be slightly
suboptimal but it greatly simplifies the situation. I vote for it.
We need to prevent our heads from cracking ;-)
Note that I would still set TIF_PATCH_PENDING flag only for tasks
that are not in the requested state.
quoted
quoted
quoted
quoted
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks, though they never cross the
+ * syscall barrier. Instead they switch over in cpu_idle_loop().
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu)
+ set_tsk_thread_flag(idle_task(cpu), TIF_PATCH_PENDING);
+ put_online_cpus();
Also this stage need to be somehow handled by CPU coming/going
handlers.
Here I think we could automatically switch any offline CPUs' idle tasks.
And something similar in klp_try_complete_transition().
We still need to make sure to do not race with the cpu_up()/cpu_down()
calls.
Hm, maybe we'd need to call cpu_hotplug_disable() before switching the
offline idle tasks?
quoted
I would use here the trick with for_each_possible_cpu() and let
the migration for the stack check.
There are a few issues with that:
1) The idle task of a missing CPU doesn't *have* a stack, so it doesn't
make much sense to try to check it.
2) We can't rely *only* on the stack check, because not all arches have
it. The other way to migrate idle tasks is from the idle loop switch
point. But if the task's CPU is down, its idle loop isn't running so
it can't migrate.
(Note this is currently a theoretical point: we currently don't allow
such arches to use the consistency model anyway because there's no
way for them to migrate kthreads.)
Good points. My only concern is that the transaction might take a long
or even forever. I am not sure if it is wise to disable cpu_hotplug
for the entire transaction.
A compromise might be to disable cpu hotplug only when the task
state is manipulated a more complex way. Hmm, cpu_hotplug_disable()
looks like a rather costly function. We should not call it in
klp_try_complete_transition(). But we could do:
1. When the patch is being enabled, disable cpu hotplug,
go through each_possible_cpu and setup the transaction
only for CPUs that are online. Then we could enable
the hotplug again.
2. Check only each_online_cpu in klp_try_complete_transition().
If all tasks are migrated, disable cpu hotplug and re-check
idle tasks on online CPUs. If any is not migrated, enable
hotplug and return failure. Othewise, continue with
completion of the transaction. [*]
3. In klp_complete_transition, update all tasks including
the offline CPUs and enable cpu hotplug again.
If the re-check in the 2nd step looks ugly, we could add some hotlug
notifiers to make sure that enabled/disabled CPUs are in a reasonable
state. We still should disable the hotplug in the 1st and 3rd step.
BTW: There is a new API for the cpu hotplug callbacks. I was involved
in one conversion. You might take inspiration in
drivers/thermal/intel_powerclamp.c. See cpuhp_setup_state_nocalls()
there.
[...]
@@ -69,6 +71,11 @@ static int livepatch_init(void){intret;+if(!klp_have_reliable_stack()&&!patch.immediate){+pr_notice("disabling consistency model!\n");+patch.immediate=true;+}
I am scared to have this in the sample module. It makes sense
to use the consistency model even for immediate patches because
it allows to remove them. But this must not be used for patches
that really require the consistency model. We should add
a big fat warning at least.
I did this so that the sample module would still work for non-x86_64
arches, for which there's currently no way to patch kthreads.
Notice I did add a warning:
pr_notice("disabling consistency model!\n");
Is the warning not fat enough?
The warning does not explain who did it, why, if it is safe, and when
this could be used. I suggest a comment like:
/*
* WARNING: Use this check only when you know what you do!
*
* This sample patch does not change the semantic of the data structures,
* locks, or return adresses. It is safe to be applied immediately.
* But we want to test and use the consistency model on supported
* architectures. It allows to remove the patch module.
*
* See Documentation/livepatch/livepatch.txt for more details, please.
*/
Also the message might be more explicit.
pr_notice("livepatch-sample: The consistency model is not supported on
this architecture. Using the immediate model that is safe enough.\n");
Ok, will try to do something like that.
quoted
Alternatively, we might allow more values for patch.immediate, e.g.
enum klp_consistency_model {
KLP_CM_IMMEDIATE,
KLP_CM_TASK,
KLP_CM_TASK_OR_IMMEDIATE,
};
Then we could do the decision on the kernel side.
But I am not sure if this would be widely used and it
it is worth the complication.
On Tue, Jan 10, 2017 at 02:00:58PM +0100, Petr Mladek wrote:
On Thu 2016-12-22 12:31:37, Josh Poimboeuf wrote:
quoted
On Thu, Dec 22, 2016 at 03:34:52PM +0100, Petr Mladek wrote:
quoted
On Wed 2016-12-21 15:25:05, Josh Poimboeuf wrote:
quoted
On Tue, Dec 20, 2016 at 06:32:46PM +0100, Petr Mladek wrote:
quoted
On Thu 2016-12-08 12:08:38, Josh Poimboeuf wrote:
quoted
Change livepatch to use a basic per-task consistency model. This is the
foundation which will eventually enable us to patch those ~10% of
security patches which change function or data semantics. This is the
biggest remaining piece needed to make livepatch more generally useful.
[1] https://lkml.kernel.org/r/20141107140458.GA21774@suse.cz
--- /dev/null+++ b/kernel/livepatch/transition.c
+ /*
+ * Enforce the order of the task->patch_state initializations and the
+ * func->transition updates to ensure that, in the enable path,
+ * klp_ftrace_handler() doesn't see a func in transition with a
+ * task->patch_state of KLP_UNDEFINED.
+ */
+ smp_wmb();
+
+ /*
+ * Set the func transition states so klp_ftrace_handler() will know to
+ * switch to the transition logic.
+ *
+ * When patching, the funcs aren't yet in the func_stack and will be
+ * made visible to the ftrace handler shortly by the calls to
+ * klp_patch_object().
+ *
+ * When unpatching, the funcs are already in the func_stack and so are
+ * already visible to the ftrace handler.
+ */
+ klp_for_each_object(patch, obj)
+ klp_for_each_func(obj, func)
+ func->transition = true;
+}
+
+/*
+ * Start the transition to the specified target patch state so tasks can begin
+ * switching to it.
+ */
+void klp_start_transition(void)
+{
+ struct task_struct *g, *task;
+ unsigned int cpu;
+
+ WARN_ON_ONCE(klp_target_state == KLP_UNDEFINED);
+
+ pr_notice("'%s': %s...\n", klp_transition_patch->mod->name,
+ klp_target_state == KLP_PATCHED ? "patching" : "unpatching");
+
+ /*
+ * If the patch can be applied or reverted immediately, skip the
+ * per-task transitions.
+ */
+ if (klp_transition_patch->immediate)
+ return;
+
+ /*
+ * Mark all normal tasks as needing a patch state update. As they pass
+ * through the syscall barrier they'll switch over to the target state
+ * (unless we switch them in klp_try_complete_transition() first).
+ */
+ read_lock(&tasklist_lock);
+ for_each_process_thread(g, task)
+ set_tsk_thread_flag(task, TIF_PATCH_PENDING);
This is called also from klp_reverse_transition(). We should set it
only when the task need migration. Also we should clear it when
the task is in the right state already.
It is not only optimization. It actually solves a race between
klp_complete_transition() and klp_update_patch_state(), see below.
I agree about the race, but if I did:
for_each_process_thread(g, task) {
if (task->patch_state != klp_target_state)
set_tsk_thread_flag(task, TIF_PATCH_PENDING);
else
clear_tsk_thread_flag(task, TIF_PATCH_PENDING);
}
It would still leave a small window where TIF_PATCH_PENDING gets set for
an already patched task, if klp_update_patch_state() is running at the
same time.
I see your point. Well, it seems that it is more complicated:
The race would be possible only when this was called from
klp_reverse_transition(). But we need to call there
rcu_synchronize() to prevent races with klp_update_patch_state()
also to prevent prelimitary patch completion.
The result is:
if (task->patch_state != klp_target_state) {
# it means that the task was already migrated before
# we reverted klp_target_state. It means that
# the TIF flag was already cleared, the related
# klp_update_patch_state() already finished (thanks
# to rcu_synchronize() and new one will be called
# only when we set the flag again
# => it is safe to set it
# we should also check and warn when the TIF flag
# was not clear before we set it here
else
# the task was not migrated before we reverted
# klp_target_state. klp_update_patch_state()
# could run in parallel but it will do the same
# what we do, clear TIF flag and keep the patch_state
# as is
# => it is safe to clear it
I agree that this is complex like hell. But it also allows use to
check that things work as we expect.
Ouch. I agree that it seems safe but it's way too hard to reason about.
And then it gets worse if you try to think about what happens when
adding another reverse operation.
quoted
If we always set the flag here and always clear it later, we might
hide a bug.
If we want to make it slightly more straightforward, we might
clear TIF flags in klp_reverse_transaction() before we revert
klp_target_state. The later rcu_synchronize() should make sure
that all migrations are finished and non-will run in parallel.
Then we could set the TIF flag only where needed here.
I think this last paragraph is important. It would simplify things
greatly and ensure we won't have klp_update_patch_state() changing
things in the background.
OK, let's clear all TIF_PATCH_PENDIG flags and call rcu_synchronize()
at the beginning of klp_reverse_transition(). It might be slightly
suboptimal but it greatly simplifies the situation. I vote for it.
We need to prevent our heads from cracking ;-)
Note that I would still set TIF_PATCH_PENDING flag only for tasks
that are not in the requested state.
Ok, sounds good.
quoted
quoted
quoted
quoted
quoted
+ read_unlock(&tasklist_lock);
+
+ /*
+ * Ditto for the idle "swapper" tasks, though they never cross the
+ * syscall barrier. Instead they switch over in cpu_idle_loop().
+ */
+ get_online_cpus();
+ for_each_online_cpu(cpu)
+ set_tsk_thread_flag(idle_task(cpu), TIF_PATCH_PENDING);
+ put_online_cpus();
Also this stage need to be somehow handled by CPU coming/going
handlers.
Here I think we could automatically switch any offline CPUs' idle tasks.
And something similar in klp_try_complete_transition().
We still need to make sure to do not race with the cpu_up()/cpu_down()
calls.
Hm, maybe we'd need to call cpu_hotplug_disable() before switching the
offline idle tasks?
quoted
I would use here the trick with for_each_possible_cpu() and let
the migration for the stack check.
There are a few issues with that:
1) The idle task of a missing CPU doesn't *have* a stack, so it doesn't
make much sense to try to check it.
2) We can't rely *only* on the stack check, because not all arches have
it. The other way to migrate idle tasks is from the idle loop switch
point. But if the task's CPU is down, its idle loop isn't running so
it can't migrate.
(Note this is currently a theoretical point: we currently don't allow
such arches to use the consistency model anyway because there's no
way for them to migrate kthreads.)
Good points. My only concern is that the transaction might take a long
or even forever. I am not sure if it is wise to disable cpu_hotplug
for the entire transaction.
A compromise might be to disable cpu hotplug only when the task
state is manipulated a more complex way. Hmm, cpu_hotplug_disable()
looks like a rather costly function. We should not call it in
klp_try_complete_transition(). But we could do:
1. When the patch is being enabled, disable cpu hotplug,
go through each_possible_cpu and setup the transaction
only for CPUs that are online. Then we could enable
the hotplug again.
2. Check only each_online_cpu in klp_try_complete_transition().
If all tasks are migrated, disable cpu hotplug and re-check
idle tasks on online CPUs. If any is not migrated, enable
hotplug and return failure. Othewise, continue with
completion of the transaction. [*]
3. In klp_complete_transition, update all tasks including
the offline CPUs and enable cpu hotplug again.
If the re-check in the 2nd step looks ugly, we could add some hotlug
notifiers to make sure that enabled/disabled CPUs are in a reasonable
state. We still should disable the hotplug in the 1st and 3rd step.
BTW: There is a new API for the cpu hotplug callbacks. I was involved
in one conversion. You might take inspiration in
drivers/thermal/intel_powerclamp.c. See cpuhp_setup_state_nocalls()
there.
Backing up a bit, although I brought up cpu_hotplug_disable(), I think I
misunderstood the race you mentioned. I actually don't think
cpu_hotplug_disable() is necessary. What do you think about something
like the following:
In klp_start_transition:
get_online_cpus();
for_each_possible_cpu(cpu)
set_tsk_thread_flag(idle_task(cpu), TIF_PATCH_PENDING);
put_online_cpus();
In klp_try_complete_transition:
get_online_cpus();
for_each_possible_cpu(cpu) {
task = idle_task(cpu);
if (cpu_online(cpu)) {
if (!klp_try_switch_task(task))
complete = false;
} else if (task->patch_state != klp_target_state) {
/* offline CPU idle tasks can be switched immediately */
clear_tsk_thread_flag(task, TIF_PATCH_PENDING);
task->patch_state = klp_target_state;
}
}
put_online_cpus();
--
Josh
On Thursday 08 December 2016 11:38 PM, Josh Poimboeuf wrote:
Add the TIF_PATCH_PENDING thread flag to enable the new livepatch
per-task consistency model for x86_64. The bit getting set indicates
the thread has a pending patch which needs to be applied when the thread
exits the kernel.
The bit is placed in the _TIF_ALLWORK_MASK macro, which results in
exit_to_usermode_loop() calling klp_update_patch_state() when it's set.
Signed-off-by: Josh Poimboeuf <redacted>