From: Petr Mladek <pmladek@suse.com>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
jikos@kernel.org, mbenes@suse.cz, joe.lawrence@redhat.com,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] livepatch: Implement livepatch hybrid mode
Date: Fri, 7 Feb 2025 10:36:03 +0100 [thread overview]
Message-ID: <Z6XUA7D0eU_YDMVp@pathway.suse.cz> (raw)
In-Reply-To: <CALOAHbB8j6RrpJAyRkzPx2U6YhjWEipRspoQQ_7cvQ+M0zgdXg@mail.gmail.com>
On Fri 2025-02-07 11:16:45, Yafang Shao wrote:
> On Fri, Feb 7, 2025 at 10:31 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > On Mon, Jan 27, 2025 at 02:35:26PM +0800, Yafang Shao wrote:
> > > - 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.
> >
> > Are you saying that atomic replace is not atomic? If so, this sounds
> > like another bug.
>
> >From my understanding, there’s a window where the original function is
> not patched.
This is a misunderstanding.
> klp_enable_patch
> + klp_init_patch
> + if (patch->replace)
> klp_add_nops(patch); <<<< set all old patches to nop
1. The "nop" entry is added into the _new_ (to-be-enabled) livepatch,
see klp_add_nops(patch). The parameter is the _newly_ enabled patch.
2. The "nop" entries are added only for functions which are currently
livepatched but they are not longer livepatched in the new
livepatch, see:
static int klp_add_object_nops(struct klp_patch *patch,
struct klp_object *old_obj)
{
[...]
klp_for_each_func(old_obj, old_func) {
func = klp_find_func(obj, old_func);
if (func)
continue; <------ Do not allocate nop
when the fuction is
implemeted in the new
livepatch.
func = klp_alloc_func_nop(old_func, obj);
if (!func)
return -ENOMEM;
}
return 0;
}
> + __klp_enable_patch
> + klp_patch_object
> + klp_patch_func
> + ops = klp_find_ops(func->old_func);
> + if (ops)
> // add the new patch to the func_stack list
> list_add_rcu(&func->stack_node, &ops->func_stack);
>
>
> klp_ftrace_handler
> + func = list_first_or_null_rcu(&ops->func_stack, struct klp_func
3. You omitted this important part of the code:
if (unlikely(func->transition)) {
patch_state = current->patch_state;
if (patch_state == KLP_TRANSITION_UNPATCHED) {
/*
----> * Use the previously patched version of the function.
----> * If no previous patches exist, continue with the
----> * original function.
*/
func = list_entry_rcu(func->stack_node.next,
struct klp_func, stack_node);
The condition "patch_state == KLP_TRANSITION_UNPATCHED" might
be a bit misleading.
The state "KLP_TRANSITION_UNPATCHED" means that it can't use
the code from the "new" livepatch => it has to fallback
to the previously used code => previous livepatch.
> + if (func->nop)
> goto unlock;
> + ftrace_regs_set_instruction_pointer(fregs, (unsigned long)func->new_func);
> Before the new atomic replace patch is added to the func_stack list,
> the old patch is already set to nop.
^^^
The nops are set in the _new_ patch for functions which will
not longer get livepatched, see the commit e1452b607c48c642
("livepatch: Add atomic replace") for more details.
> If klp_ftrace_handler() is
> triggered at this point, it will effectively do nothing—in other
> words, it will execute the original function.
> I might be wrong.
Fortunately, you are wrong. This would be a serious violation of
the consistency model and livepatches modifying some semantic would
blow up systems.
Best Regards,
Petr
next prev parent reply other threads:[~2025-02-07 9:36 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 ` [RFC PATCH 2/2] livepatch: Implement livepatch hybrid mode Yafang Shao
2025-01-27 14:31 ` 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 [this message]
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=Z6XUA7D0eU_YDMVp@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=laoar.shao@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
/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