mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-27 06:35:12 +07:00
d67a537209
The atomic replace and cumulative patches were introduced as a more secure
way to handle dependent patches. They simplify the logic:
+ Any new cumulative patch is supposed to take over shadow variables
and changes made by callbacks from previous livepatches.
+ All replaced patches are discarded and the modules can be unloaded.
As a result, there is only one scenario when a cumulative livepatch
gets disabled.
The different handling of "normal" and cumulative patches might cause
confusion. It would make sense to keep only one mode. On the other hand,
it would be rude to enforce using the cumulative livepatches even for
trivial and independent (hot) fixes.
However, the stack of patches is not really necessary any longer.
The patch ordering was never clearly visible via the sysfs interface.
Also the "normal" patches need a lot of caution anyway.
Note that the list of enabled patches is still necessary but the ordering
is not longer enforced.
Otherwise, the code is ready to disable livepatches in an random order.
Namely, klp_check_stack_func() always looks for the function from
the livepatch that is being disabled. klp_func structures are just
removed from the related func_stack. Finally, the ftrace handlers
is removed only when the func_stack becomes empty.
Signed-off-by: Petr Mladek <pmladek@suse.com>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
103 lines
3.8 KiB
Plaintext
103 lines
3.8 KiB
Plaintext
===================================
|
|
Atomic Replace & Cumulative Patches
|
|
===================================
|
|
|
|
There might be dependencies between livepatches. If multiple patches need
|
|
to do different changes to the same function(s) then we need to define
|
|
an order in which the patches will be installed. And function implementations
|
|
from any newer livepatch must be done on top of the older ones.
|
|
|
|
This might become a maintenance nightmare. Especially when more patches
|
|
modified the same function in different ways.
|
|
|
|
An elegant solution comes with the feature called "Atomic Replace". It allows
|
|
creation of so called "Cumulative Patches". They include all wanted changes
|
|
from all older livepatches and completely replace them in one transition.
|
|
|
|
Usage
|
|
-----
|
|
|
|
The atomic replace can be enabled by setting "replace" flag in struct klp_patch,
|
|
for example:
|
|
|
|
static struct klp_patch patch = {
|
|
.mod = THIS_MODULE,
|
|
.objs = objs,
|
|
.replace = true,
|
|
};
|
|
|
|
All processes are then migrated to use the code only from the new patch.
|
|
Once the transition is finished, all older patches are automatically
|
|
disabled.
|
|
|
|
Ftrace handlers are transparently removed from functions that are no
|
|
longer modified by the new cumulative patch.
|
|
|
|
As a result, the livepatch authors might maintain sources only for one
|
|
cumulative patch. It helps to keep the patch consistent while adding or
|
|
removing various fixes or features.
|
|
|
|
Users could keep only the last patch installed on the system after
|
|
the transition to has finished. It helps to clearly see what code is
|
|
actually in use. Also the livepatch might then be seen as a "normal"
|
|
module that modifies the kernel behavior. The only difference is that
|
|
it can be updated at runtime without breaking its functionality.
|
|
|
|
|
|
Features
|
|
--------
|
|
|
|
The atomic replace allows:
|
|
|
|
+ Atomically revert some functions in a previous patch while
|
|
upgrading other functions.
|
|
|
|
+ Remove eventual performance impact caused by core redirection
|
|
for functions that are no longer patched.
|
|
|
|
+ Decrease user confusion about dependencies between livepatches.
|
|
|
|
|
|
Limitations:
|
|
------------
|
|
|
|
+ Once the operation finishes, there is no straightforward way
|
|
to reverse it and restore the replaced patches atomically.
|
|
|
|
A good practice is to set .replace flag in any released livepatch.
|
|
Then re-adding an older livepatch is equivalent to downgrading
|
|
to that patch. This is safe as long as the livepatches do _not_ do
|
|
extra modifications in (un)patching callbacks or in the module_init()
|
|
or module_exit() functions, see below.
|
|
|
|
Also note that the replaced patch can be removed and loaded again
|
|
only when the transition was not forced.
|
|
|
|
|
|
+ Only the (un)patching callbacks from the _new_ cumulative livepatch are
|
|
executed. Any callbacks from the replaced patches are ignored.
|
|
|
|
In other words, the cumulative patch is responsible for doing any actions
|
|
that are necessary to properly replace any older patch.
|
|
|
|
As a result, it might be dangerous to replace newer cumulative patches by
|
|
older ones. The old livepatches might not provide the necessary callbacks.
|
|
|
|
This might be seen as a limitation in some scenarios. But it makes life
|
|
easier in many others. Only the new cumulative livepatch knows what
|
|
fixes/features are added/removed and what special actions are necessary
|
|
for a smooth transition.
|
|
|
|
In any case, it would be a nightmare to think about the order of
|
|
the various callbacks and their interactions if the callbacks from all
|
|
enabled patches were called.
|
|
|
|
|
|
+ There is no special handling of shadow variables. Livepatch authors
|
|
must create their own rules how to pass them from one cumulative
|
|
patch to the other. Especially that they should not blindly remove
|
|
them in module_exit() functions.
|
|
|
|
A good practice might be to remove shadow variables in the post-unpatch
|
|
callback. It is called only when the livepatch is properly disabled.
|