Re: [PATCH] livepatch: add load/unload hooks to objects
On Tue, Aug 30, 2016 at 04:43:30PM +0200, Petr Mladek wrote: > On Mon 2016-08-29 11:16:28, Christopher Arges wrote: > > On Mon, Aug 29, 2016 at 05:23:30PM +0200, Petr Mladek wrote: > > > On Fri 2016-08-26 13:50:27, Chris J Arges wrote: > > > > It can be useful to execute hook functions whenever a livepatch is > > > > applied > > > > or unapplied to a particular object. Currently this is possible by > > > > writing > > > > logic in the __init function of the livepatch kernel module. However to > > > > handle executing functions when a module loads requires an additional > > > > module notifier to be set up with the correct priority. > > > > > > > > By using load/unload hooks we can execute these functions using the > > > > existing livepatch notifier infrastructure and ensure consistent > > > > ordering > > > > of notifications. > > > > > > > > The load hook executes right before enabling functions, and the unload > > > > hook > > > > executes right after disabling functions. > > > > > > Could you please provide an example(s), what these hooks will be > > > useful for? > > > > > > The callbacks will still need to be implemented in the patch module. > > > If they are generally useful, it would make sense to implement them > > > in the livepatch code directly, so they get more review and are > > > shared. > > > > > > Best Regards, > > > Petr > > > > These hooks could be used as a yet another tool to implement a specific > > patch. > > And yes, the callbacks to these hooks will be part of the patch module. > > > > If there are 'hooks' that are applicable generically to livepatch they > > should > > absolutely go into the core code. > > > > As an example, CVE-2015-5307 requires that a bit be set in the exception > > bitmap > > in order to handle #AC exceptions. One could write code in the init > > function of > > the patch that checks if the module is loaded and then applies this fix. Or > > if > > hooks are available, write a load hook that sets this structure whenever the > > patch is loaded and the kvm module is loaded. In the future when patch > > unloading is possible, one could also write an unload hook to return the > > exception bitmap back to normal as the patched function(s) may not be > > available > > any longer. > > Also this change looks racy when done by the hooks. I did not study it > in detail. But I wonder if it is correct to set the bit in the mask > before update_exception_bitmap() and ac_interception() are avalable. > > My feeling is that you try to find a solution for something that > need to be supported by a more strict consistency model. You > try to change values of structures that might already be in use > and we need to be very careful here. > This is a good point. Perhaps the strict consistency will obviate the need for hooks of this sort. > Your hooks are called for both already loaded objects and for objects > that are being loaded. Something that is safe for a module in COMMING > state might be dangerous for an already loaded one. > > Best Regards, > Petr Yea maybe this should have been [DRAFT RFC], I think more thought will need to be done here about how to handle modifying existing data structures (and I see you already have a proposal for this during plumbers). In both cases; however I see the need for allowing patch authors to be able to write some custom logic to safely handle changing existing data structures. This could also be dependent on any user-space tooling requirements too. --chris
Re: [PATCH] livepatch: add load/unload hooks to objects
On Tue, Aug 30, 2016 at 04:43:30PM +0200, Petr Mladek wrote: > On Mon 2016-08-29 11:16:28, Christopher Arges wrote: > > On Mon, Aug 29, 2016 at 05:23:30PM +0200, Petr Mladek wrote: > > > On Fri 2016-08-26 13:50:27, Chris J Arges wrote: > > > > It can be useful to execute hook functions whenever a livepatch is > > > > applied > > > > or unapplied to a particular object. Currently this is possible by > > > > writing > > > > logic in the __init function of the livepatch kernel module. However to > > > > handle executing functions when a module loads requires an additional > > > > module notifier to be set up with the correct priority. > > > > > > > > By using load/unload hooks we can execute these functions using the > > > > existing livepatch notifier infrastructure and ensure consistent > > > > ordering > > > > of notifications. > > > > > > > > The load hook executes right before enabling functions, and the unload > > > > hook > > > > executes right after disabling functions. > > > > > > Could you please provide an example(s), what these hooks will be > > > useful for? > > > > > > The callbacks will still need to be implemented in the patch module. > > > If they are generally useful, it would make sense to implement them > > > in the livepatch code directly, so they get more review and are > > > shared. > > > > > > Best Regards, > > > Petr > > > > These hooks could be used as a yet another tool to implement a specific > > patch. > > And yes, the callbacks to these hooks will be part of the patch module. > > > > If there are 'hooks' that are applicable generically to livepatch they > > should > > absolutely go into the core code. > > > > As an example, CVE-2015-5307 requires that a bit be set in the exception > > bitmap > > in order to handle #AC exceptions. One could write code in the init > > function of > > the patch that checks if the module is loaded and then applies this fix. Or > > if > > hooks are available, write a load hook that sets this structure whenever the > > patch is loaded and the kvm module is loaded. In the future when patch > > unloading is possible, one could also write an unload hook to return the > > exception bitmap back to normal as the patched function(s) may not be > > available > > any longer. > > Also this change looks racy when done by the hooks. I did not study it > in detail. But I wonder if it is correct to set the bit in the mask > before update_exception_bitmap() and ac_interception() are avalable. > > My feeling is that you try to find a solution for something that > need to be supported by a more strict consistency model. You > try to change values of structures that might already be in use > and we need to be very careful here. > This is a good point. Perhaps the strict consistency will obviate the need for hooks of this sort. > Your hooks are called for both already loaded objects and for objects > that are being loaded. Something that is safe for a module in COMMING > state might be dangerous for an already loaded one. > > Best Regards, > Petr Yea maybe this should have been [DRAFT RFC], I think more thought will need to be done here about how to handle modifying existing data structures (and I see you already have a proposal for this during plumbers). In both cases; however I see the need for allowing patch authors to be able to write some custom logic to safely handle changing existing data structures. This could also be dependent on any user-space tooling requirements too. --chris
Re: [PATCH] livepatch: add load/unload hooks to objects
On Tue, Aug 30, 2016 at 11:41:28AM +0200, Jiri Kosina wrote: > On Mon, 29 Aug 2016, Christopher Arges wrote: > > > Another example is CVE-2016-2117. Here we need to unset NETIF_F_SG on a > > particular device. If the device is already loaded we need a way to > > fixup hw_features on an already allocated network device. Again this > > could be done in the init code of the patch, but a nicer solution would > > be to do this on a load/unload hook appropriately. > > I am afraid this is more complicated than what you describe. You can't > just unset NETIF_F_SG and be done with it; look for example what might > happen if you clear the flag while skb_segment() is running and gcc is > refetching netdev_features_t (there is no READ_ONCE() for that). The same > holds for __ip6_append_data(). > I am not saying this can't be worked around, but it's way much more > complicated than just clearing a bit in a callback. > > -- > Jiri Kosina > SUSE Labs > Jiri, Yes this example was meant more for showing how something like a load/unload hook could make patching certain situations easier for a patch author. Essentially it would be nice to have a place to run code right before patching, without having to write an additional notifier for module load events. In this specific example, for safety of setting hw_features perhaps one could check if a set of functions are on the stacks of any tasks before executing these hooks. Or ignore any skbs that are already in flight. --chris
Re: [PATCH] livepatch: add load/unload hooks to objects
On Tue, Aug 30, 2016 at 11:41:28AM +0200, Jiri Kosina wrote: > On Mon, 29 Aug 2016, Christopher Arges wrote: > > > Another example is CVE-2016-2117. Here we need to unset NETIF_F_SG on a > > particular device. If the device is already loaded we need a way to > > fixup hw_features on an already allocated network device. Again this > > could be done in the init code of the patch, but a nicer solution would > > be to do this on a load/unload hook appropriately. > > I am afraid this is more complicated than what you describe. You can't > just unset NETIF_F_SG and be done with it; look for example what might > happen if you clear the flag while skb_segment() is running and gcc is > refetching netdev_features_t (there is no READ_ONCE() for that). The same > holds for __ip6_append_data(). > I am not saying this can't be worked around, but it's way much more > complicated than just clearing a bit in a callback. > > -- > Jiri Kosina > SUSE Labs > Jiri, Yes this example was meant more for showing how something like a load/unload hook could make patching certain situations easier for a patch author. Essentially it would be nice to have a place to run code right before patching, without having to write an additional notifier for module load events. In this specific example, for safety of setting hw_features perhaps one could check if a set of functions are on the stacks of any tasks before executing these hooks. Or ignore any skbs that are already in flight. --chris
Re: [PATCH] livepatch: add load/unload hooks to objects
On Mon, Aug 29, 2016 at 05:23:30PM +0200, Petr Mladek wrote: > On Fri 2016-08-26 13:50:27, Chris J Arges wrote: > > It can be useful to execute hook functions whenever a livepatch is applied > > or unapplied to a particular object. Currently this is possible by writing > > logic in the __init function of the livepatch kernel module. However to > > handle executing functions when a module loads requires an additional > > module notifier to be set up with the correct priority. > > > > By using load/unload hooks we can execute these functions using the > > existing livepatch notifier infrastructure and ensure consistent ordering > > of notifications. > > > > The load hook executes right before enabling functions, and the unload hook > > executes right after disabling functions. > > Could you please provide an example(s), what these hooks will be > useful for? > > The callbacks will still need to be implemented in the patch module. > If they are generally useful, it would make sense to implement them > in the livepatch code directly, so they get more review and are > shared. > > Best Regards, > Petr These hooks could be used as a yet another tool to implement a specific patch. And yes, the callbacks to these hooks will be part of the patch module. If there are 'hooks' that are applicable generically to livepatch they should absolutely go into the core code. As an example, CVE-2015-5307 requires that a bit be set in the exception bitmap in order to handle #AC exceptions. One could write code in the init function of the patch that checks if the module is loaded and then applies this fix. Or if hooks are available, write a load hook that sets this structure whenever the patch is loaded and the kvm module is loaded. In the future when patch unloading is possible, one could also write an unload hook to return the exception bitmap back to normal as the patched function(s) may not be available any longer. Another example is CVE-2016-2117. Here we need to unset NETIF_F_SG on a particular device. If the device is already loaded we need a way to fixup hw_features on an already allocated network device. Again this could be done in the init code of the patch, but a nicer solution would be to do this on a load/unload hook appropriately. In general these hooks would help to better handle what needs to be setup before we patch and cleanup after we unpatch. While one could write their own code and notifiers in the patch init (and later exit) to do this, having a hook makes this implementation cleaner and can tie it to a specific object. In addition, tools like kpatch-build for livepatch (or whatever comes in the future) could also utilize these hooks in much of the same way that kpatch does already. --chris
Re: [PATCH] livepatch: add load/unload hooks to objects
On Mon, Aug 29, 2016 at 05:23:30PM +0200, Petr Mladek wrote: > On Fri 2016-08-26 13:50:27, Chris J Arges wrote: > > It can be useful to execute hook functions whenever a livepatch is applied > > or unapplied to a particular object. Currently this is possible by writing > > logic in the __init function of the livepatch kernel module. However to > > handle executing functions when a module loads requires an additional > > module notifier to be set up with the correct priority. > > > > By using load/unload hooks we can execute these functions using the > > existing livepatch notifier infrastructure and ensure consistent ordering > > of notifications. > > > > The load hook executes right before enabling functions, and the unload hook > > executes right after disabling functions. > > Could you please provide an example(s), what these hooks will be > useful for? > > The callbacks will still need to be implemented in the patch module. > If they are generally useful, it would make sense to implement them > in the livepatch code directly, so they get more review and are > shared. > > Best Regards, > Petr These hooks could be used as a yet another tool to implement a specific patch. And yes, the callbacks to these hooks will be part of the patch module. If there are 'hooks' that are applicable generically to livepatch they should absolutely go into the core code. As an example, CVE-2015-5307 requires that a bit be set in the exception bitmap in order to handle #AC exceptions. One could write code in the init function of the patch that checks if the module is loaded and then applies this fix. Or if hooks are available, write a load hook that sets this structure whenever the patch is loaded and the kvm module is loaded. In the future when patch unloading is possible, one could also write an unload hook to return the exception bitmap back to normal as the patched function(s) may not be available any longer. Another example is CVE-2016-2117. Here we need to unset NETIF_F_SG on a particular device. If the device is already loaded we need a way to fixup hw_features on an already allocated network device. Again this could be done in the init code of the patch, but a nicer solution would be to do this on a load/unload hook appropriately. In general these hooks would help to better handle what needs to be setup before we patch and cleanup after we unpatch. While one could write their own code and notifiers in the patch init (and later exit) to do this, having a hook makes this implementation cleaner and can tie it to a specific object. In addition, tools like kpatch-build for livepatch (or whatever comes in the future) could also utilize these hooks in much of the same way that kpatch does already. --chris
Re: [PATCH 0/2] Fix issue with alternatives/paravirt patches
On Tue, Jul 05, 2016 at 10:34:58PM -0400, Jessica Yu wrote:
> Hi,
>
> A few months ago, Chris Arges reported a bug involving alternatives/paravirt
> patching that was discussed here [1] and here [2]. To briefly summarize the
> bug, patch modules that contained .altinstructions or .parainstructions
> sections would break because these alternative/paravirt patches would be
> applied first by the module loader (see x86 module_finalize()), then
> livepatch would later clobber these patches when applying per-object
> relocations. This lead to crashes and unpredictable behavior.
>
> One conclusion we reached from our last discussion was that we will
> need to introduce some arch-specific code to address this problem.
> This patchset presents a possible fix for the bug by adding a new
> arch-specific arch_klp_init_object_loaded() function that by default
> does nothing but can be overridden by different arches.
>
> To fix this issue for x86, since we can access a patch module's Elf
> sections through mod->klp_info, we can simply delay the calls to
> apply_paravirt() and apply_alternatives() to arch_klp_init_object_loaded(),
> which is called after relocations have been written for an object.
> In addition, for patch modules, .parainstructions and .altinstructions are
> prefixed by ".klp.arch.${objname}" so that the module loader ignores them
> and livepatch can apply them manually.
>
> Currently for kpatch, we don't support including jump table sections in
> the patch module, and supporting .smp_locks is currently broken, so we
> don't consider those sections (for now).
>
> I did some light testing with some patches to kvm and verified that the
> original issue reported in [2] was fixed.
>
> Based on linux-next.
>
Jessica,
I was able to test these patches on top of linux-next. I took your kpatch
branch and hacked it a bit to get it working and was able to
apply a patch to 'kvm_arch_vm_ioctl' while running a VM workload.
Great job!
Tested-by: Chris J Arges
--chris
> [1] http://thread.gmane.org/gmane.linux.kernel/2185604/
> [2] https://github.com/dynup/kpatch/issues/580
>
> Jessica Yu (2):
> livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks
> livepatch/x86: apply alternatives and paravirt patches after relocations
>
> arch/x86/kernel/Makefile| 1 +
> arch/x86/kernel/livepatch.c | 66
> +
> include/linux/livepatch.h | 3 +++
> kernel/livepatch/core.c | 12 +++--
> 4 files changed, 80 insertions(+), 2 deletions(-)
> create mode 100644 arch/x86/kernel/livepatch.c
>
> --
> 2.4.3
>
Re: [PATCH 0/2] Fix issue with alternatives/paravirt patches
On Tue, Jul 05, 2016 at 10:34:58PM -0400, Jessica Yu wrote:
> Hi,
>
> A few months ago, Chris Arges reported a bug involving alternatives/paravirt
> patching that was discussed here [1] and here [2]. To briefly summarize the
> bug, patch modules that contained .altinstructions or .parainstructions
> sections would break because these alternative/paravirt patches would be
> applied first by the module loader (see x86 module_finalize()), then
> livepatch would later clobber these patches when applying per-object
> relocations. This lead to crashes and unpredictable behavior.
>
> One conclusion we reached from our last discussion was that we will
> need to introduce some arch-specific code to address this problem.
> This patchset presents a possible fix for the bug by adding a new
> arch-specific arch_klp_init_object_loaded() function that by default
> does nothing but can be overridden by different arches.
>
> To fix this issue for x86, since we can access a patch module's Elf
> sections through mod->klp_info, we can simply delay the calls to
> apply_paravirt() and apply_alternatives() to arch_klp_init_object_loaded(),
> which is called after relocations have been written for an object.
> In addition, for patch modules, .parainstructions and .altinstructions are
> prefixed by ".klp.arch.${objname}" so that the module loader ignores them
> and livepatch can apply them manually.
>
> Currently for kpatch, we don't support including jump table sections in
> the patch module, and supporting .smp_locks is currently broken, so we
> don't consider those sections (for now).
>
> I did some light testing with some patches to kvm and verified that the
> original issue reported in [2] was fixed.
>
> Based on linux-next.
>
Jessica,
I was able to test these patches on top of linux-next. I took your kpatch
branch and hacked it a bit to get it working and was able to
apply a patch to 'kvm_arch_vm_ioctl' while running a VM workload.
Great job!
Tested-by: Chris J Arges
--chris
> [1] http://thread.gmane.org/gmane.linux.kernel/2185604/
> [2] https://github.com/dynup/kpatch/issues/580
>
> Jessica Yu (2):
> livepatch: use arch_klp_init_object_loaded() to finish arch-specific tasks
> livepatch/x86: apply alternatives and paravirt patches after relocations
>
> arch/x86/kernel/Makefile| 1 +
> arch/x86/kernel/livepatch.c | 66
> +
> include/linux/livepatch.h | 3 +++
> kernel/livepatch/core.c | 12 +++--
> 4 files changed, 80 insertions(+), 2 deletions(-)
> create mode 100644 arch/x86/kernel/livepatch.c
>
> --
> 2.4.3
>
Re: [PATCH v2] livepatch: allow removal of a disabled patch
On Wed, Jun 01, 2016 at 10:31:59AM +0200, Miroslav Benes wrote:
> 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(>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
> ---
> Based on Josh's v2 of the consistency model.
>
> 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(-)
>
> diff --git a/Documentation/livepatch/livepatch.txt
> b/Documentation/livepatch/livepatch.txt
> index bee86d0fe854..a05124258a73 100644
> --- a/Documentation/livepatch/livepatch.txt
> +++ b/Documentation/livepatch/livepatch.txt
> @@ -272,8 +272,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
> ===
> @@ -444,24 +451,6 @@ See Documentation/ABI/testing/sysfs-kernel-livepatch for
> more details.
> 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//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.
>
> diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
> index cd2dfd95e109..a9651c6e1b52 100644
> --- a/include/linux/livepatch.h
> +++ b/include/linux/livepatch.h
> @@ -23,6 +23,7 @@
>
> #include
> #include
> +#include
>
> #if IS_ENABLED(CONFIG_LIVEPATCH)
>
> @@ -114,6 +115,7 @@ struct klp_object {
> * @list:list node for global list of registered patches
> * @kobj:kobject for sysfs resources
> * @enabled: the patch is enabled (but operation may be incomplete)
> + * @finish: for waiting till it is
Re: [PATCH v2] livepatch: allow removal of a disabled patch
On Wed, Jun 01, 2016 at 10:31:59AM +0200, Miroslav Benes wrote:
> 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(>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
> ---
> Based on Josh's v2 of the consistency model.
>
> 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(-)
>
> diff --git a/Documentation/livepatch/livepatch.txt
> b/Documentation/livepatch/livepatch.txt
> index bee86d0fe854..a05124258a73 100644
> --- a/Documentation/livepatch/livepatch.txt
> +++ b/Documentation/livepatch/livepatch.txt
> @@ -272,8 +272,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
> ===
> @@ -444,24 +451,6 @@ See Documentation/ABI/testing/sysfs-kernel-livepatch for
> more details.
> 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//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.
>
> diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
> index cd2dfd95e109..a9651c6e1b52 100644
> --- a/include/linux/livepatch.h
> +++ b/include/linux/livepatch.h
> @@ -23,6 +23,7 @@
>
> #include
> #include
> +#include
>
> #if IS_ENABLED(CONFIG_LIVEPATCH)
>
> @@ -114,6 +115,7 @@ struct klp_object {
> * @list:list node for global list of registered patches
> * @kobj:kobject for sysfs resources
> * @enabled: the patch is enabled (but operation may be incomplete)
> + * @finish: for waiting till it is safe to remove the
