Live Patching
 help / color / mirror / Atom feed
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

  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