From: Yafang Shao <laoar.shao@gmail.com>
To: jpoimboe@kernel.org, jikos@kernel.org, mbenes@suse.cz,
pmladek@suse.com, joe.lawrence@redhat.com
Cc: live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
Yafang Shao <laoar.shao@gmail.com>
Subject: [RFC PATCH 2/2] livepatch: Implement livepatch hybrid mode
Date: Mon, 27 Jan 2025 14:35:26 +0800 [thread overview]
Message-ID: <20250127063526.76687-3-laoar.shao@gmail.com> (raw)
In-Reply-To: <20250127063526.76687-1-laoar.shao@gmail.com>
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@mail.gmail.com/ [0]
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
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
next prev parent reply other threads:[~2025-01-27 6:35 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-27 6:35 [RFC PATCH 0/2] livepatch: Add support for hybrid mode Yafang Shao
2025-01-27 6:35 ` [RFC PATCH 1/2] livepatch: Add replaceable attribute Yafang Shao
2025-01-27 6:35 ` Yafang Shao [this message]
2025-01-27 14:31 ` [RFC PATCH 2/2] livepatch: Implement livepatch hybrid mode Petr Mladek
2025-01-27 15:34 ` Yafang Shao
2025-02-04 13:21 ` Petr Mladek
2025-02-05 2:54 ` Yafang Shao
2025-02-05 16:03 ` Petr Mladek
2025-02-06 2:35 ` Yafang Shao
2025-02-07 13:58 ` Petr Mladek
2025-02-08 3:08 ` Yafang Shao
2025-02-07 2:31 ` Josh Poimboeuf
2025-02-07 3:16 ` Yafang Shao
2025-02-07 9:36 ` Petr Mladek
2025-02-08 2:14 ` Yafang Shao
2025-02-07 16:59 ` Josh Poimboeuf
2025-02-08 3:38 ` Yafang Shao
2025-01-27 13:46 ` [RFC PATCH 0/2] livepatch: Add support for " Petr Mladek
2025-01-27 14:22 ` Yafang Shao
2025-01-31 13:18 ` Miroslav Benes
2025-02-03 9:44 ` Yafang Shao
2025-02-03 21:53 ` Song Liu
2025-02-05 14:42 ` Yafang Shao
2025-02-05 17:59 ` Song Liu
2025-02-06 2:54 ` Yafang Shao
2025-02-06 18:00 ` Song Liu
2025-02-08 6:41 ` Yafang Shao
2025-02-08 15:47 ` Alexei Starovoitov
2025-02-08 19:32 ` Josh Poimboeuf
2025-02-09 3:56 ` Alexei Starovoitov
2025-02-10 2:39 ` Yafang Shao
2025-02-04 13:05 ` Petr Mladek
2025-02-05 6:16 ` Yafang Shao
2025-02-07 11:00 ` Petr Mladek
2025-02-08 2:49 ` Yafang Shao
2025-02-10 2:50 ` Yafang Shao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250127063526.76687-3-laoar.shao@gmail.com \
--to=laoar.shao@gmail.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=pmladek@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox