All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eugene Syromiatnikov <esyr@redhat.com>
To: Yonghong Song <yhs@fb.com>
Cc: Jiri Olsa <jolsa@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf v3 2/2] bpf_trace: bail out from bpf_kprobe_multi_link_attach when in compat
Date: Wed, 18 May 2022 22:03:58 +0200	[thread overview]
Message-ID: <20220518200358.GB29226@asgard.redhat.com> (raw)
In-Reply-To: <7bbb4a95-0d12-2a8f-9503-2613d774eaaa@fb.com>

On Wed, May 18, 2022 at 09:55:05AM -0700, Yonghong Song wrote:
> 
> 
> On 5/18/22 5:22 AM, Eugene Syromiatnikov wrote:
> >Since bpf_kprobe_multi_link_attach doesn't support 32-bit kernels
> >for whatever reason, having it enabled for compat processes on 64-bit
> >kernels makes even less sense due to discrepances in the type sizes
> >that it does not handle.
> 
> If I understand correctly, the reason is due to
> in libbpf we have
> struct bpf_link_create_opts {
>         size_t sz; /* size of this struct for forward/backward compatibility
> */
>         __u32 flags;
>         union bpf_iter_link_info *iter_info;
>         __u32 iter_info_len;
>         __u32 target_btf_id;
>         union {
>                 struct {
>                         __u64 bpf_cookie;
>                 } perf_event;
>                 struct {
>                         __u32 flags;
>                         __u32 cnt;
>                         const char **syms;
>                         const unsigned long *addrs;
>                         const __u64 *cookies;
>                 } kprobe_multi;
>         };
>         size_t :0;
> };
> 
> Note that we have `const unsigned long *addrs;`
> 
> If we have 32-bit user space application and 64bit kernel,
> and we will have userspace 32-bit pointers and kernel as
> 64bit pointers and current kernel doesn't handle 32-bit
> user pointer properly.
> 
> Consider this may involve libbpf uapi change, maybe
> we should change "const unsigned long *addrs;" to
> "const __u64 *addrs;" considering we haven't freeze
> libbpf UAPI yet.
> 
> Otherwise, we stick to current code with this patch,
> it will make it difficult to support 32-bit app with
> 64-bit kernel for kprobe_multi in the future due to
> uapi issues.
> 
> WDYT?

As 32 bit arches are "unsupported" currently, the change would be more
a semantic one rather then practical;  I don't mind having it here (basically,
the tools/* part of [1]), though (assuming it is still possible to get it
in 5.18).

[1] https://lore.kernel.org/lkml/6ef675aeeea442fa8fc168cd1cb4e4e474f65a3f.1652772731.git.esyr@redhat.com/

> >
> >Fixes: 0dcac272540613d4 ("bpf: Add multi kprobe link")
> >Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
> >---
> >  kernel/trace/bpf_trace.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> >index 212faa4..2f83489 100644
> >--- a/kernel/trace/bpf_trace.c
> >+++ b/kernel/trace/bpf_trace.c
> >@@ -2412,7 +2412,7 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
> >  	int err;
> >  	/* no support for 32bit archs yet */
> >-	if (sizeof(u64) != sizeof(void *))
> >+	if (sizeof(u64) != sizeof(void *) || in_compat_syscall())
> >  		return -EOPNOTSUPP;
> >  	if (prog->expected_attach_type != BPF_TRACE_KPROBE_MULTI)
> 


  reply	other threads:[~2022-05-18 20:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-18 12:22 [PATCH bpf v3 0/2] Fix kprobe_multi interface issues for 5.18 Eugene Syromiatnikov
2022-05-18 12:22 ` [PATCH bpf v3 1/2] bpf_trace: check size for overflow in bpf_kprobe_multi_link_attach Eugene Syromiatnikov
2022-05-18 16:34   ` Yonghong Song
2022-05-18 20:00     ` Eugene Syromiatnikov
2022-05-18 20:41       ` Yonghong Song
2022-05-18 12:22 ` [PATCH bpf v3 2/2] bpf_trace: bail out from bpf_kprobe_multi_link_attach when in compat Eugene Syromiatnikov
2022-05-18 16:55   ` Yonghong Song
2022-05-18 20:03     ` Eugene Syromiatnikov [this message]
2022-05-18 20:57       ` Yonghong Song

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=20220518200358.GB29226@asgard.redhat.com \
    --to=esyr@redhat.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.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 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.