From: Jiri Olsa <olsajiri@gmail.com>
To: Viktor Malik <vmalik@redhat.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>
Subject: Re: [PATCH bpf-next 1/2] bpf: Fix attaching fentry/fexit/fmod_ret/lsm to modules
Date: Mon, 28 Nov 2022 10:07:49 +0100 [thread overview]
Message-ID: <Y4R6ZfrhVxsHBD22@krava> (raw)
In-Reply-To: <2ec861621e283ba2a54f7e939eafed1c29f77bf4.1669216157.git.vmalik@redhat.com>
On Mon, Nov 28, 2022 at 08:26:29AM +0100, Viktor Malik wrote:
> When attaching fentry/fexit/fmod_ret/lsm to a function located in a
> module without specifying the target program, the verifier tries to find
> the address to attach to in kallsyms. This is always done by searching
> the entire kallsyms, not respecting the module in which the function is
> located.
>
> This approach causes an incorrect attachment address to be computed if
> the function to attach to is shadowed by a function of the same name
> located earlier in kallsyms.
>
> Since the attachment must contain the BTF of the program to attach to,
> we may extract the module name from it (if the attach target is a
> module) and search for the function address in the correct module.
>
> Signed-off-by: Viktor Malik <vmalik@redhat.com>
> ---
> include/linux/btf.h | 1 +
> kernel/bpf/btf.c | 5 +++++
> kernel/bpf/verifier.c | 9 ++++++++-
> 3 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/btf.h b/include/linux/btf.h
> index 9ed00077db6e..bdbf3eb7083d 100644
> --- a/include/linux/btf.h
> +++ b/include/linux/btf.h
> @@ -187,6 +187,7 @@ u32 btf_obj_id(const struct btf *btf);
> bool btf_is_kernel(const struct btf *btf);
> bool btf_is_module(const struct btf *btf);
> struct module *btf_try_get_module(const struct btf *btf);
> +const char *btf_module_name(const struct btf *btf);
> u32 btf_nr_types(const struct btf *btf);
> bool btf_member_is_reg_int(const struct btf *btf, const struct btf_type *s,
> const struct btf_member *m,
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 1a59cc7ad730..211fcbb7649d 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -7192,6 +7192,11 @@ bool btf_is_module(const struct btf *btf)
> return btf->kernel_btf && strcmp(btf->name, "vmlinux") != 0;
> }
>
> +const char *btf_module_name(const struct btf *btf)
> +{
> + return btf->name;
> +}
> +
> enum {
> BTF_MODULE_F_LIVE = (1 << 0),
> };
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 9528a066cfa5..acbe62a73559 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -16343,7 +16343,14 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
> else
> addr = (long) tgt_prog->aux->func[subprog]->bpf_func;
> } else {
> - addr = kallsyms_lookup_name(tname);
> + if (btf_is_module(btf)) {
> + char tmodname[MODULE_NAME_LEN + KSYM_NAME_LEN + 1];
looks good.. would be nice to have module_kallsyms lookup function that
takes module name and symbol separately so we won't waste stack on that..
especially when module_kallsyms_lookup_name just separates it back again
and does module lookup.. but not sure how much pain it'd be
jirka
> + snprintf(tmodname, sizeof(tmodname), "%s:%s",
> + btf_module_name(btf), tname);
> + addr = module_kallsyms_lookup_name(tmodname);
> + }
> + else
> + addr = kallsyms_lookup_name(tname);
> if (!addr) {
> bpf_log(log,
> "The address of function %s cannot be found\n",
> --
> 2.38.1
>
next prev parent reply other threads:[~2022-11-28 9:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 7:26 [PATCH bpf-next 0/2] Fix attaching fentry/fexit/fmod_ret/lsm to modules Viktor Malik
2022-11-28 7:26 ` [PATCH bpf-next 1/2] bpf: " Viktor Malik
2022-11-28 9:07 ` Jiri Olsa [this message]
2022-11-28 20:06 ` Hao Luo
2022-11-28 7:26 ` [PATCH bpf-next 2/2] bpf/selftests: Test fentry attachment to shadowed functions Viktor Malik
2022-11-28 21:14 ` Hao Luo
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=Y4R6ZfrhVxsHBD22@krava \
--to=olsajiri@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=vmalik@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox