21 May, 2019
1 commit
-
Based on 2 normalized pattern(s):
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 licensesthis 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 [based]
[from] [clk] [highbank] [c] you should have received a copy of the
gnu general public license along with this program if not see http
www gnu org licensesextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 355 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Kate Stewart
Reviewed-by: Jilayne Lovejoy
Reviewed-by: Steve Winslow
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190519154041.837383322@linutronix.de
Signed-off-by: Greg Kroah-Hartman
12 Jan, 2019
1 commit
-
The possibility to re-enable a registered patch was useful for immediate
patches where the livepatch module had to stay until the system reboot.
The improved consistency model allows to achieve the same result by
unloading and loading the livepatch module again.Also we are going to add a feature called atomic replace. It will allow
to create a patch that would replace all already registered patches.
The aim is to handle dependent patches more securely. It will obsolete
the stack of patches that helped to handle the dependencies so far.
Then it might be unclear when a cumulative patch re-enabling is safe.It would be complicated to support the many modes. Instead we could
actually make the API and code easier to understand.Therefore, remove the two step public API. All the checks and init calls
are moved from klp_register_patch() to klp_enabled_patch(). Also the patch
is automatically freed, including the sysfs interface when the transition
to the disabled state is completed.As a result, there is never a disabled patch on the top of the stack.
Therefore we do not need to check the stack in __klp_enable_patch().
And we could simplify the check in __klp_disable_patch().Also the API and logic is much easier. It is enough to call
klp_enable_patch() in module_init() call. The patch can be disabled
by writing '0' into /sys/kernel/livepatch//enabled. Then the module
can be removed once the transition finishes and sysfs interface is freed.The only problem is how to free the structures and kobjects safely.
The operation is triggered from the sysfs interface. We could not put
the related kobject from there because it would cause lock inversion
between klp_mutex and kernfs locks, see kn->count lockdep map.Therefore, offload the free task to a workqueue. It is perfectly fine:
+ The patch can no longer be used in the livepatch operations.
+ The module could not be removed until the free operation finishes
and module_put() is called.+ The operation is asynchronous already when the first
klp_try_complete_transition() fails and another call
is queued with a delay.Suggested-by: Josh Poimboeuf
Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
Acked-by: Josh Poimboeuf
Signed-off-by: Jiri Kosina
11 Jan, 2018
1 commit
-
Immediate flag has been used to disable per-task consistency and patch
all tasks immediately. It could be useful if the patch doesn't change any
function or data semantics.However, it causes problems on its own. The consistency problem is
currently broken with respect to immediate patches.func a
patches 1i
2i
3When the patch 3 is applied, only 2i function is checked (by stack
checking facility). There might be a task sleeping in 1i though. Such
task is migrated to 3, because we do not check 1i in
klp_check_stack_func() at all.Coming atomic replace feature would be easier to implement and more
reliable without immediate.Thus, remove immediate feature completely and save us from the problems.
Note that force feature has the similar problem. However it is
considered as a last resort. If used, administrator should not apply any
new live patches and should plan for reboot into an updated kernel.The architectures would now need to provide HAVE_RELIABLE_STACKTRACE to
fully support livepatch.Signed-off-by: Miroslav Benes
Acked-by: Josh Poimboeuf
Signed-off-by: Jiri Kosina
19 Oct, 2017
1 commit
-
Provide livepatch modules a klp_object (un)patching notification
mechanism. Pre and post-(un)patch callbacks allow livepatch modules to
setup or synchronize changes that would be difficult to support in only
patched-or-unpatched code contexts.Callbacks can be registered for target module or vmlinux klp_objects,
but each implementation is klp_object specific.- Pre-(un)patch callbacks run before any (un)patching transition
starts.- Post-(un)patch callbacks run once an object has been (un)patched and
the klp_patch fully transitioned to its target state.Example use cases include modification of global data and registration
of newly available services/handlers.See Documentation/livepatch/callbacks.txt for details and
samples/livepatch/ for examples.Signed-off-by: Joe Lawrence
Acked-by: Josh Poimboeuf
Acked-by: Miroslav Benes
Signed-off-by: Jiri Kosina
