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 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.