~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

TOMOYO Linux Cross Reference
Linux/Documentation/livepatch/cumulative-patches.rst

Version: ~ [ linux-6.12-rc7 ] ~ [ linux-6.11.7 ] ~ [ linux-6.10.14 ] ~ [ linux-6.9.12 ] ~ [ linux-6.8.12 ] ~ [ linux-6.7.12 ] ~ [ linux-6.6.60 ] ~ [ linux-6.5.13 ] ~ [ linux-6.4.16 ] ~ [ linux-6.3.13 ] ~ [ linux-6.2.16 ] ~ [ linux-6.1.116 ] ~ [ linux-6.0.19 ] ~ [ linux-5.19.17 ] ~ [ linux-5.18.19 ] ~ [ linux-5.17.15 ] ~ [ linux-5.16.20 ] ~ [ linux-5.15.171 ] ~ [ linux-5.14.21 ] ~ [ linux-5.13.19 ] ~ [ linux-5.12.19 ] ~ [ linux-5.11.22 ] ~ [ linux-5.10.229 ] ~ [ linux-5.9.16 ] ~ [ linux-5.8.18 ] ~ [ linux-5.7.19 ] ~ [ linux-5.6.19 ] ~ [ linux-5.5.19 ] ~ [ linux-5.4.285 ] ~ [ linux-5.3.18 ] ~ [ linux-5.2.21 ] ~ [ linux-5.1.21 ] ~ [ linux-5.0.21 ] ~ [ linux-4.20.17 ] ~ [ linux-4.19.323 ] ~ [ linux-4.18.20 ] ~ [ linux-4.17.19 ] ~ [ linux-4.16.18 ] ~ [ linux-4.15.18 ] ~ [ linux-4.14.336 ] ~ [ linux-4.13.16 ] ~ [ linux-4.12.14 ] ~ [ linux-4.11.12 ] ~ [ linux-4.10.17 ] ~ [ linux-4.9.337 ] ~ [ linux-4.4.302 ] ~ [ linux-3.10.108 ] ~ [ linux-2.6.32.71 ] ~ [ linux-2.6.0 ] ~ [ linux-2.4.37.11 ] ~ [ unix-v6-master ] ~ [ ccs-tools-1.8.12 ] ~ [ policy-sample ] ~
Architecture: ~ [ i386 ] ~ [ alpha ] ~ [ m68k ] ~ [ mips ] ~ [ ppc ] ~ [ sparc ] ~ [ sparc64 ] ~

Diff markup

Differences between /Documentation/livepatch/cumulative-patches.rst (Version linux-6.12-rc7) and /Documentation/livepatch/cumulative-patches.rst (Version linux-5.16.20)


  1 ===================================                 1 ===================================
  2 Atomic Replace & Cumulative Patches                 2 Atomic Replace & Cumulative Patches
  3 ===================================                 3 ===================================
  4                                                     4 
  5 There might be dependencies between livepatche      5 There might be dependencies between livepatches. If multiple patches need
  6 to do different changes to the same function(s      6 to do different changes to the same function(s) then we need to define
  7 an order in which the patches will be installe      7 an order in which the patches will be installed. And function implementations
  8 from any newer livepatch must be done on top o      8 from any newer livepatch must be done on top of the older ones.
  9                                                     9 
 10 This might become a maintenance nightmare. Esp     10 This might become a maintenance nightmare. Especially when more patches
 11 modified the same function in different ways.      11 modified the same function in different ways.
 12                                                    12 
 13 An elegant solution comes with the feature cal     13 An elegant solution comes with the feature called "Atomic Replace". It allows
 14 creation of so called "Cumulative Patches". Th     14 creation of so called "Cumulative Patches". They include all wanted changes
 15 from all older livepatches and completely repl     15 from all older livepatches and completely replace them in one transition.
 16                                                    16 
 17 Usage                                              17 Usage
 18 -----                                              18 -----
 19                                                    19 
 20 The atomic replace can be enabled by setting "     20 The atomic replace can be enabled by setting "replace" flag in struct klp_patch,
 21 for example::                                      21 for example::
 22                                                    22 
 23         static struct klp_patch patch = {          23         static struct klp_patch patch = {
 24                 .mod = THIS_MODULE,                24                 .mod = THIS_MODULE,
 25                 .objs = objs,                      25                 .objs = objs,
 26                 .replace = true,                   26                 .replace = true,
 27         };                                         27         };
 28                                                    28 
 29 All processes are then migrated to use the cod     29 All processes are then migrated to use the code only from the new patch.
 30 Once the transition is finished, all older pat     30 Once the transition is finished, all older patches are automatically
 31 disabled.                                          31 disabled.
 32                                                    32 
 33 Ftrace handlers are transparently removed from     33 Ftrace handlers are transparently removed from functions that are no
 34 longer modified by the new cumulative patch.       34 longer modified by the new cumulative patch.
 35                                                    35 
 36 As a result, the livepatch authors might maint     36 As a result, the livepatch authors might maintain sources only for one
 37 cumulative patch. It helps to keep the patch c     37 cumulative patch. It helps to keep the patch consistent while adding or
 38 removing various fixes or features.                38 removing various fixes or features.
 39                                                    39 
 40 Users could keep only the last patch installed     40 Users could keep only the last patch installed on the system after
 41 the transition to has finished. It helps to cl     41 the transition to has finished. It helps to clearly see what code is
 42 actually in use. Also the livepatch might then     42 actually in use. Also the livepatch might then be seen as a "normal"
 43 module that modifies the kernel behavior. The      43 module that modifies the kernel behavior. The only difference is that
 44 it can be updated at runtime without breaking      44 it can be updated at runtime without breaking its functionality.
 45                                                    45 
 46                                                    46 
 47 Features                                           47 Features
 48 --------                                           48 --------
 49                                                    49 
 50 The atomic replace allows:                         50 The atomic replace allows:
 51                                                    51 
 52   - Atomically revert some functions in a prev     52   - Atomically revert some functions in a previous patch while
 53     upgrading other functions.                     53     upgrading other functions.
 54                                                    54 
 55   - Remove eventual performance impact caused      55   - Remove eventual performance impact caused by core redirection
 56     for functions that are no longer patched.      56     for functions that are no longer patched.
 57                                                    57 
 58   - Decrease user confusion about dependencies     58   - Decrease user confusion about dependencies between livepatches.
 59                                                    59 
 60                                                    60 
 61 Limitations:                                       61 Limitations:
 62 ------------                                       62 ------------
 63                                                    63 
 64   - Once the operation finishes, there is no s     64   - Once the operation finishes, there is no straightforward way
 65     to reverse it and restore the replaced pat     65     to reverse it and restore the replaced patches atomically.
 66                                                    66 
 67     A good practice is to set .replace flag in     67     A good practice is to set .replace flag in any released livepatch.
 68     Then re-adding an older livepatch is equiv     68     Then re-adding an older livepatch is equivalent to downgrading
 69     to that patch. This is safe as long as the     69     to that patch. This is safe as long as the livepatches do _not_ do
 70     extra modifications in (un)patching callba     70     extra modifications in (un)patching callbacks or in the module_init()
 71     or module_exit() functions, see below.         71     or module_exit() functions, see below.
 72                                                    72 
 73     Also note that the replaced patch can be r     73     Also note that the replaced patch can be removed and loaded again
 74     only when the transition was not forced.       74     only when the transition was not forced.
 75                                                    75 
 76                                                    76 
 77   - Only the (un)patching callbacks from the _     77   - Only the (un)patching callbacks from the _new_ cumulative livepatch are
 78     executed. Any callbacks from the replaced      78     executed. Any callbacks from the replaced patches are ignored.
 79                                                    79 
 80     In other words, the cumulative patch is re     80     In other words, the cumulative patch is responsible for doing any actions
 81     that are necessary to properly replace any     81     that are necessary to properly replace any older patch.
 82                                                    82 
 83     As a result, it might be dangerous to repl     83     As a result, it might be dangerous to replace newer cumulative patches by
 84     older ones. The old livepatches might not      84     older ones. The old livepatches might not provide the necessary callbacks.
 85                                                    85 
 86     This might be seen as a limitation in some     86     This might be seen as a limitation in some scenarios. But it makes life
 87     easier in many others. Only the new cumula     87     easier in many others. Only the new cumulative livepatch knows what
 88     fixes/features are added/removed and what      88     fixes/features are added/removed and what special actions are necessary
 89     for a smooth transition.                       89     for a smooth transition.
 90                                                    90 
 91     In any case, it would be a nightmare to th     91     In any case, it would be a nightmare to think about the order of
 92     the various callbacks and their interactio     92     the various callbacks and their interactions if the callbacks from all
 93     enabled patches were called.                   93     enabled patches were called.
 94                                                    94 
 95                                                    95 
 96   - There is no special handling of shadow var     96   - There is no special handling of shadow variables. Livepatch authors
 97     must create their own rules how to pass th     97     must create their own rules how to pass them from one cumulative
 98     patch to the other. Especially that they s     98     patch to the other. Especially that they should not blindly remove
 99     them in module_exit() functions.               99     them in module_exit() functions.
100                                                   100 
101     A good practice might be to remove shadow     101     A good practice might be to remove shadow variables in the post-unpatch
102     callback. It is called only when the livep    102     callback. It is called only when the livepatch is properly disabled.
                                                      

~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

kernel.org | git.kernel.org | LWN.net | Project Home | SVN repository | Mail admin

Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.

sflogo.php