| Message ID | e7d42f8f48ab4323ba460b4c843c27f3c475f106.1669787912.git.vmalik@redhat.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | BPF |
| Headers | show |
| Series | Fix attaching fentry/fexit/fmod_ret/lsm to modules | expand |
On Tue, Nov 29, 2022 at 10:54 PM Viktor Malik <vmalik@redhat.com> 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> > --- Looks like we need to define a trivial kallsyms_lookup_name_in_module() in !CONFIG_MODULES. With that added, this patch looks good to me. Acked-by: Hao Luo <haoluo@google.com>
On 12/1/22 20:26, Hao Luo wrote: > On Tue, Nov 29, 2022 at 10:54 PM Viktor Malik <vmalik@redhat.com> 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> >> --- > > Looks like we need to define a trivial > kallsyms_lookup_name_in_module() in !CONFIG_MODULES. With that added, > this patch looks good to me. Right, I missed that, thanks! I'll fix it and post v3 soon. > > Acked-by: Hao Luo <haoluo@google.com> >
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 d11cbf8cece7..2815944ddfa4 100644 --- a/kernel/bpf/btf.c +++ b/kernel/bpf/btf.c @@ -7206,6 +7206,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 4e7f1d085e53..41f6a8722a97 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -16451,7 +16451,10 @@ 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)) + addr = kallsyms_lookup_name_in_module(btf_module_name(btf), tname); + else + addr = kallsyms_lookup_name(tname); if (!addr) { bpf_log(log, "The address of function %s cannot be found\n",
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 | 5 ++++- 3 files changed, 10 insertions(+), 1 deletion(-)