From: Jiri Olsa <olsajiri@gmail.com>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@chromium.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Martynas Pumputis <m@lambda.lt>,
Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
Subject: Re: [PATCH RFC bpf-next 4/4] selftests/bpf: Fix kprobe get_func_ip tests for CONFIG_X86_KERNEL_IBT
Date: Sun, 17 Jul 2022 23:43:08 +0200 [thread overview]
Message-ID: <YtSCbIA+6JtRF/Ch@krava> (raw)
In-Reply-To: <YsdbQ4vJheLWOa0a@krava>
On Fri, Jul 08, 2022 at 12:16:35AM +0200, Jiri Olsa wrote:
> On Tue, Jul 05, 2022 at 10:29:17PM -0700, Andrii Nakryiko wrote:
> > On Tue, Jul 5, 2022 at 12:04 PM Jiri Olsa <jolsa@kernel.org> wrote:
> > >
> > > The kprobe can be placed anywhere and user must be aware
> > > of the underlying instructions. Therefore fixing just
> > > the bpf program to 'fix' the address to match the actual
> > > function address when CONFIG_X86_KERNEL_IBT is enabled.
> > >
> > > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > > ---
> > > tools/testing/selftests/bpf/progs/get_func_ip_test.c | 7 +++++--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/tools/testing/selftests/bpf/progs/get_func_ip_test.c b/tools/testing/selftests/bpf/progs/get_func_ip_test.c
> > > index a587aeca5ae0..220d56b7c1dc 100644
> > > --- a/tools/testing/selftests/bpf/progs/get_func_ip_test.c
> > > +++ b/tools/testing/selftests/bpf/progs/get_func_ip_test.c
> > > @@ -2,6 +2,7 @@
> > > #include <linux/bpf.h>
> > > #include <bpf/bpf_helpers.h>
> > > #include <bpf/bpf_tracing.h>
> > > +#include <stdbool.h>
> > >
> > > char _license[] SEC("license") = "GPL";
> > >
> > > @@ -13,6 +14,8 @@ extern const void bpf_modify_return_test __ksym;
> > > extern const void bpf_fentry_test6 __ksym;
> > > extern const void bpf_fentry_test7 __ksym;
> > >
> > > +extern bool CONFIG_X86_KERNEL_IBT __kconfig __weak;
> > > +
> > > __u64 test1_result = 0;
> > > SEC("fentry/bpf_fentry_test1")
> > > int BPF_PROG(test1, int a)
> > > @@ -37,7 +40,7 @@ __u64 test3_result = 0;
> > > SEC("kprobe/bpf_fentry_test3")
> > > int test3(struct pt_regs *ctx)
> > > {
> > > - __u64 addr = bpf_get_func_ip(ctx);
> > > + __u64 addr = bpf_get_func_ip(ctx) - (CONFIG_X86_KERNEL_IBT ? 4 : 0);
> >
> > so for kprobe bpf_get_func_ip() gets an address with 5 byte
> > compensation for `call __fentry__`, but not for endr? Why can't we
> > compensate for endbr inside the kernel code as well? I'd imagine we
> > either do no compensation (and thus we get &bpf_fentry_test3+5 or
> > &bpf_fentry_test3+9, depending on CONFIG_X86_KERNEL_IBT) or full
> > compensation (and thus always get &bpf_fentry_test3), but this
> > in-between solution seems to be the worst of both worlds?...
>
> hm rigth, I guess we should be able to do that in bpf_get_func_ip,
> I'll check
sorry for late follow up..
so the problem is that you can place kprobe anywhere in the function
(on instruction boundary) but the IBT adjustment of kprobe address is
made only if it's at the function entry and there's endbr instruction
and that kprobe address is what we return in helper:
BPF_CALL_1(bpf_get_func_ip_kprobe, struct pt_regs *, regs)
{
struct kprobe *kp = kprobe_running();
return kp ? (uintptr_t)kp->addr : 0;
}
so the adjustment would work only for address at function entry, but
would be wrong for address within the function
perhaps we could add flag to kprobe to indicate the addr adjustment
was done and use it in helper
but that's why I thought I'd keep bpf_get_func_ip_kprobe as it and
leave it up to user
kprobe_multi and trampolines are different, because they can be
only at the function entry, so we can adjust the ip properly
jirka
next prev parent reply other threads:[~2022-07-17 21:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-05 19:03 [PATCH RFC bpf-next 0/4] bpf: Fixes for CONFIG_X86_KERNEL_IBT Jiri Olsa
2022-07-05 19:03 ` [PATCH RFC bpf-next 1/4] bpf: Adjust kprobe_multi entry_ip " Jiri Olsa
2022-07-05 19:03 ` [PATCH RFC bpf-next 2/4] bpf: Use given function address for trampoline ip arg Jiri Olsa
2022-07-05 19:03 ` [PATCH RFC bpf-next 3/4] selftests/bpf: Disable kprobe attach test with offset for CONFIG_X86_KERNEL_IBT Jiri Olsa
2022-07-05 19:03 ` [PATCH RFC bpf-next 4/4] selftests/bpf: Fix kprobe get_func_ip tests " Jiri Olsa
2022-07-06 5:29 ` Andrii Nakryiko
2022-07-07 22:16 ` Jiri Olsa
2022-07-17 21:43 ` Jiri Olsa [this message]
2022-07-18 11:09 ` Martynas Pumputis
2022-07-18 12:48 ` Jiri Olsa
2022-07-19 8:24 ` Jiri Olsa
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=YtSCbIA+6JtRF/Ch@krava \
--to=olsajiri@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.org \
--cc=m@lambda.lt \
--cc=mhiramat@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
--cc=yutaro.hayakawa@isovalent.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;
as well as URLs for NNTP newsgroup(s).