The atomic replace livepatch mechanism was introduced to handle scenarios where we want to unload a specific livepatch without unloading others. However, its current implementation has significant shortcomings, making it less than ideal in practice. Below are the key downsides: - It is expensive During testing with frequent replacements of an old livepatch, random RCU warnings were observed: [19578271.779605] rcu_tasks_wait_gp: rcu_tasks grace period 642409 is 10024 jiffies old. [19578390.073790] rcu_tasks_wait_gp: rcu_tasks grace period 642417 is 10185 jiffies old. [19578423.034065] rcu_tasks_wait_gp: rcu_tasks grace period 642421 is 10150 jiffies old. [19578564.144591] rcu_tasks_wait_gp: rcu_tasks grace period 642449 is 10174 jiffies old. [19578601.064614] rcu_tasks_wait_gp: rcu_tasks grace period 642453 is 10168 jiffies old. [19578663.920123] rcu_tasks_wait_gp: rcu_tasks grace period 642469 is 10167 jiffies old. [19578872.990496] rcu_tasks_wait_gp: rcu_tasks grace period 642529 is 10215 jiffies old. [19578903.190292] rcu_tasks_wait_gp: rcu_tasks grace period 642529 is 40415 jiffies old. [19579017.965500] rcu_tasks_wait_gp: rcu_tasks grace period 642577 is 10174 jiffies old. [19579033.981425] rcu_tasks_wait_gp: rcu_tasks grace period 642581 is 10143 jiffies old. [19579153.092599] rcu_tasks_wait_gp: rcu_tasks grace period 642625 is 10188 jiffies old. This indicates that atomic replacement can cause performance issues, particularly with RCU synchronization under frequent use. - Potential Risks During Replacement One known issue involves replacing livepatched versions of critical functions such as do_exit(). During the replacement process, a panic might occur, as highlighted in [0]. Other potential risks may also arise due to inconsistencies or race conditions during transitions. - Temporary Loss of Patching During the replacement process, the old patch is set to a NOP (no-operation) before the new patch is fully applied. This creates a window where the function temporarily reverts to its original, unpatched state. If the old patch fixed a critical issue (e.g., one that prevented a system panic), the system could become vulnerable to that issue during the transition. The current atomic replacement approach replaces all old livepatches, even when such a sweeping change is unnecessary. This can be improved by introducing a hybrid mode, which allows the coexistence of both atomic replace and non atomic replace livepatches. In the hybrid mode: - Specific livepatches can be marked as "non-replaceable" to ensure they remain active and unaffected during replacements. - Other livepatches can be marked as "replaceable," allowing targeted replacements of only those patches. This selective approach would reduce unnecessary transitions, lower the risk of temporary patch loss, and mitigate performance issues during livepatch replacement. Link: https://lore.kernel.org/live-patching/CALOAHbA9WHPjeZKUcUkwULagQjTMfqAdAg+akqPzbZ7Byc=qrw@xxxxxxxxxxxxxx/ [0] Signed-off-by: Yafang Shao <laoar.shao@xxxxxxxxx> --- kernel/livepatch/core.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c index 5e0c2caa0af8..f820b50c1b26 100644 --- a/kernel/livepatch/core.c +++ b/kernel/livepatch/core.c @@ -658,6 +658,8 @@ static int klp_add_nops(struct klp_patch *patch) klp_for_each_object(old_patch, old_obj) { int err; + if (!old_patch->replaceable) + continue; err = klp_add_object_nops(patch, old_obj); if (err) return err; @@ -830,6 +832,8 @@ void klp_free_replaced_patches_async(struct klp_patch *new_patch) klp_for_each_patch_safe(old_patch, tmp_patch) { if (old_patch == new_patch) return; + if (!old_patch->replaceable) + continue; klp_free_patch_async(old_patch); } } @@ -1232,6 +1236,8 @@ void klp_unpatch_replaced_patches(struct klp_patch *new_patch) if (old_patch == new_patch) return; + if (!old_patch->replaceable) + continue; old_patch->enabled = false; klp_unpatch_objects(old_patch); } -- 2.43.5
