All of lore.kernel.org
 help / color / mirror / Atom feed
From: Menglong Dong <menglong.dong@linux.dev>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: jpoimboe@kernel.org, jikos@kernel.org, mbenes@suse.cz,
	pmladek@suse.com, joe.lawrence@redhat.com, rostedt@goodmis.org,
	mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
	kpsingh@kernel.org, mattbobrowski@google.com, song@kernel.org,
	jolsa@kernel.org, ast@kernel.org, daniel@iogearbox.net,
	andrii@kernel.org, martin.lau@linux.dev, eddyz87@gmail.com,
	memxor@gmail.com, yonghong.song@linux.dev,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [RFC PATCH 2/4] trace: Allow kprobes to override livepatched functions
Date: Fri, 03 Apr 2026 18:25:59 +0800	[thread overview]
Message-ID: <3036842.e9J7NaK4W3@7940hx> (raw)
In-Reply-To: <CALOAHbDnNba_w_nWH3-S9GAXw0+VKuLTh1gy5hy9Yqgeo4C0iA@mail.gmail.com>

On 2026/4/2 21:20 Yafang Shao <laoar.shao@gmail.com> write:
> On Thu, Apr 2, 2026 at 8:48 PM Menglong Dong <menglong.dong@linux.dev> wrote:
> >
> > On 2026/4/2 17:26, Yafang Shao wrote:
> > > Introduce the ability for kprobes to override the return values of
> > > functions that have been livepatched. This functionality is guarded by the
> > > CONFIG_KPROBE_OVERRIDE_KLP_FUNC configuration option.
> >
> > Hi, Yafang. This is a interesting idea.
> >
[...]
> 
> +/* noclone to avoid bond_get_slave_hook.constprop.0 */
> +__attribute__((__noclone__, __noinline__))
> +int bond_get_slave_hook(struct sk_buff *skb, u32 hash, unsigned int count)
> +{
> +       return -1;
> +}

Hi, yafang.

I see what you mean now. So you want to allow BPF program override
the return of all the kernel functions in a KLP module.

I think the security problem is a big issue. Image that we have a KLP
in our environment. Any users can crash the kernel by hook a BPF
program on it with the calling of bpf_override_write().

What's more, this is a little weird for me. If we allow to use bpf_override_return()
for the kernel functions in a KLP, why not we allow it in a common kernel
module, as KLP is a kind of kernel module. Then, why not we allow to
use it for all the kernel functions?

Can we mark the "bond_get_slave_hook" with ALLOW_ERROR_INJECTION() in
your example? Then we can override its return directly. This is a more
reasonable for me. With ALLOW_ERROR_INJECTION(), we are telling people that
anyone can modify the return of this function safely.

WDYT?

BTW, this is a BPF modification, so maybe we can use "bpf: xxx" for the title
of this patch. Then, the BPF maintainers can notice this patch ;)

Thanks!
Menglong Dong

> 
>  static struct slave *bond_xmit_3ad_xor_slave_get(struct bonding *bond,
>                                                  struct sk_buff *skb,
>                                                  struct bond_up_slave *slaves)
>  {
>         struct slave *slave;
>         unsigned int count;
> +       int slave_idx;
>         u32 hash;
> 
>         hash = bond_xmit_hash(bond, skb);
> @@ -5188,6 +5198,13 @@ static struct slave
> *bond_xmit_3ad_xor_slave_get(struct bonding *bond,
>         if (unlikely(!count))
>                 return NULL;
> 
> +       /* Try BPF hook first - returns slave index directly */
> +       slave_idx = bond_get_slave_hook(skb, hash, count);
> +       /* If BPF hook returned valid slave index, use it */
> +       if (slave_idx >= 0 && slave_idx < count) {
> +               slave = slaves->arr[slave_idx];
> +               return slave;
> +       }
>         slave = slaves->arr[hash % count];
>         return slave;
>  }
> 
> - The BPF program
> 
> SEC("kprobe/bond_get_slave_hook")
> int BPF_KPROBE(slave_selector, struct sk_buff *skb, u32 hash, u32 count)
> {
>         unsigned short net_hdr_off;
>         unsigned char *head;
>         struct iphdr iph;
>         int *slave_idx;
>         __u32 daddr;
> 
>         __u16 proto = BPF_CORE_READ(skb, protocol);
>         if (proto != bpf_htons(0x0800))
>                 return 0;
> 
>         head = BPF_CORE_READ(skb, head);
>         net_hdr_off = BPF_CORE_READ(skb, network_header);
> 
>         if (bpf_probe_read_kernel(&iph, sizeof(iph), head + net_hdr_off) != 0)
>                 return 0;
> 
>         daddr = iph.daddr;
>         slave_idx = bpf_map_lookup_elem(&ip_slave_map, &daddr);
>         if (slave_idx) {
>                 int idx = *slave_idx;
> 
>                 if (idx >= 0 && idx < (int)count)
>                         bpf_override_return(ctx, idx);
>         }
>         return 0;
> }
> 
> >
> > BTW, if we allow the usage of bpf_override_return() on the KLP patched
> > function, we should allow the usage of BPF_MODIFY_RETURN on this
> > case too, right?
> 
> It's a possibility, but I haven't tested that specifically yet.
> 
> -- 
> Regards
> Yafang




  reply	other threads:[~2026-04-03 10:26 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-02  9:26 [RFC PATCH 0/4] trace, livepatch: Allow kprobe return overriding for livepatched functions Yafang Shao
2026-04-02  9:26 ` [RFC PATCH 1/4] trace: Simplify kprobe overridable function check Yafang Shao
2026-04-02 13:13   ` Masami Hiramatsu
2026-04-02  9:26 ` [RFC PATCH 2/4] trace: Allow kprobes to override livepatched functions Yafang Shao
2026-04-02 12:48   ` Menglong Dong
2026-04-02 13:20     ` Yafang Shao
2026-04-03 10:25       ` Menglong Dong [this message]
2026-04-03 11:30         ` Steven Rostedt
2026-04-03 13:30           ` Yafang Shao
2026-04-03 14:26             ` Alexei Starovoitov
2026-04-03 16:00               ` Yafang Shao
2026-04-03 13:26         ` Yafang Shao
2026-04-09  9:47   ` Miroslav Benes
2026-04-12 13:08     ` Yafang Shao
2026-04-02  9:26 ` [RFC PATCH 3/4] livepatch: Add "replaceable" attribute to klp_patch Yafang Shao
2026-04-03 16:19   ` Song Liu
2026-04-03 20:55     ` Dylan Hatch
2026-04-03 21:35       ` Song Liu
2026-04-06 11:08         ` Yafang Shao
2026-04-06 18:11           ` Song Liu
2026-04-06 21:12             ` Joe Lawrence
2026-04-07  2:54               ` Song Liu
2026-04-07  3:16                 ` Yafang Shao
2026-04-07  9:45                   ` Yafang Shao
2026-04-07 15:08                     ` Petr Mladek
2026-04-07 23:09                       ` Song Liu
2026-04-08 11:10                         ` Petr Mladek
2026-04-08  2:40                       ` Yafang Shao
2026-04-08 11:43                         ` Petr Mladek
2026-04-08 18:19                           ` Song Liu
2026-04-09  7:36                             ` Petr Mladek
2026-04-12 12:18                               ` Yafang Shao
2026-04-12 12:09                           ` Yafang Shao
2026-04-07 13:52           ` Petr Mladek
2026-04-02  9:26 ` [RFC PATCH 4/4] livepatch: Implement livepatch hybrid mode Yafang Shao
2026-04-03 16:06 ` [RFC PATCH 0/4] trace, livepatch: Allow kprobe return overriding for livepatched functions Song Liu
2026-04-06 10:55   ` Yafang Shao
2026-04-06 18:26     ` Song Liu
2026-04-07  2:21       ` Yafang Shao
2026-04-07  2:46         ` Song Liu
2026-04-07  3:13           ` Yafang Shao
2026-04-08  6:51             ` Song Liu
2026-04-09 10:08             ` Miroslav Benes
2026-04-12 13:30               ` Yafang Shao
2026-04-06  5:36 ` Christoph Hellwig
2026-04-06 10:57   ` Yafang Shao
2026-04-10  4:38 ` Masami Hiramatsu
2026-04-12 13:50   ` Yafang Shao
2026-04-15  0:48     ` Masami Hiramatsu

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=3036842.e9J7NaK4W3@7940hx \
    --to=menglong.dong@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jolsa@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mattbobrowski@google.com \
    --cc=mbenes@suse.cz \
    --cc=memxor@gmail.com \
    --cc=mhiramat@kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.