Re: CAP_SYS_ADMIN required for BTF in modules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20/07/2023 18:40, Ivan Babrou wrote:
> Hello,
> 
> I noticed that CAP_SYS_ADMIN is required to attach BTF enabled probes
> for modules. Attaching them for compiled-in points works just fine
> without it.
> 
> The reason is that libbpf calls into bpf_obj_get_next_id:
> 
> #0  bpf_obj_get_next_id (start_id=start_id@entry=0,
> next_id=next_id@entry=0x7fffcbffe578, cmd=cmd@entry=23) at bpf.c:908
> #1  0x00000000008bc08a in bpf_btf_get_next_id
> (start_id=start_id@entry=0, next_id=next_id@entry=0x7fffcbffe578) at
> bpf.c:930
> #2  0x00000000008ca252 in load_module_btfs
> (obj=obj@entry=0x7fffc4004a40) at libbpf.c:5365
> #3  0x00000000008ca508 in find_kernel_btf_id
> (btf_type_id=0x7fffcbffe73c, btf_obj_fd=0x7fffcbffe738,
> attach_type=BPF_TRACE_FENTRY, attach_name=0xf8b647
> "nfnetlink_rcv_msg", obj=0x7fffc4004a40) at libbpf.c:9057
> #4  find_kernel_btf_id (obj=0x7fffc4004a40, attach_name=0xf8b647
> "nfnetlink_rcv_msg", attach_type=BPF_TRACE_FENTRY,
> btf_obj_fd=0x7fffcbffe738, btf_type_id=0x7fffcbffe73c) at
> libbpf.c:9042
> #5  0x00000000008ca755 in libbpf_find_attach_btf_id
> (btf_type_id=0x7fffcbffe73c, btf_obj_fd=0x7fffcbffe738,
> attach_name=0xf8b647 "nfnetlink_rcv_msg", prog=0x7fffc401d5b0) at
> libbpf.c:9109
> #6  libbpf_prepare_prog_load (prog=0x7fffc401d5b0,
> opts=0x7fffcbffe7c0, cookie=<optimized out>) at libbpf.c:6668
> #7  0x00000000008c3eb5 in bpf_object_load_prog
> (obj=obj@entry=0x7fffc4004a40, prog=prog@entry=0x7fffc401d5b0,
> insns=0x7fffc400ccc0, insns_cnt=87,
> license=license@entry=0x7fffc4004a50 "GPL",
>     kern_version=<optimized out>, prog_fd=0x7fffc401d628) at libbpf.c:6741
> #8  0x00000000008d0294 in bpf_object__load_progs (log_level=<optimized
> out>, obj=<optimized out>) at libbpf.c:7085
> #9  bpf_object_load (extra_log_level=0, target_btf_path=0x0,
> obj=<optimized out>) at libbpf.c:7656
> #10 bpf_object__load (obj=<optimized out>) at libbpf.c:7703
> #11 0x00000000008b90e7 in _cgo_58a414c63447_Cfunc_bpf_object__load
> (v=0xc000237bd8) at cgo-gcc-prolog:1232
> #12 0x000000000046c224 in runtime.asmcgocall () at
> /usr/local/go/src/runtime/asm_amd64.s:848
> #13 0x00007fffcbfff260 in ?? ()
> #14 0x000000000041020e in runtime.persistentalloc.func1 () at
> /usr/local/go/src/runtime/malloc.go:1393
> #15 0x000000000046a3a9 in runtime.systemstack () at
> /usr/local/go/src/runtime/asm_amd64.s:496
> #16 0x00007fffffffdf6f in ?? ()
> #17 0x0100000000000000 in ?? ()
> #18 0x0000000000800000 in
> github.com/golang/protobuf/ptypes/timestamp.file_github_com_golang_protobuf_ptypes_timestamp_timestamp_proto_init
> ()
>     at /home/builder/go/pkg/mod/github.com/golang/protobuf@v1.5.2/ptypes/timestamp/timestamp.pb.go:57
> #19 0x0000000000000000 in ?? ()
> 
> Here it is in code, where it happens after vmlinux does not find the
> requested id:
> 
> * https://github.com/libbpf/libbpf/blob/v1.2.0/src/libbpf.c#L9219
> 
> And in turn bpf_obj_get_next_id requires CAP_SYS_ADMIN here:
> 
> * https://elixir.bootlin.com/linux/v6.5-rc1/source/kernel/bpf/syscall.c#L3790
> 
> The requirement comes from commit 34ad558 ("bpf: Add
> BPF_(PROG|MAP)_GET_NEXT_ID command") from v4.13:
> 
> * https://github.com/torvalds/linux/commit/34ad558
> 
> There's also this in the commit message: It is currently limited to
> CAP_SYS_ADMIN which we can consider to lift it in followup patches.
> 
> Later in v5.4 commit 341dfcf ("btf: expose BTF info through sysfs")
> exposed BTF info via sysfs:
> 
> * https://github.com/torvalds/linux/commit/341dfcf
> 
> This info is world readable and it doesn't require any special capabilities:
> 
> static struct bin_attribute bin_attr_btf_vmlinux __ro_after_init = {
>   .attr = { .name = "vmlinux", .mode = 0444, },
>   .read = btf_vmlinux_read,
> };
> 
> $ ls -l /sys/kernel/btf/vmlinux
> -r--r--r-- 1 root root 4438336 Jul 13 06:33 /sys/kernel/btf/vmlinux
> 
> My question is then: do we still need CAP_SYS_ADMIN? Should it be
> CAP_BPF / CAP_PERFMON (available since v5.8) or should we drop the
> requirement completely, since we expose vmlinux btf without any
> restrictions?
> 
> I'm happy to submit a patch.
> 

I think it would be possible to gather module BTF data via
/sys/kernel/btf instead of via iterating through the BTF objects, which
is where lack of CAP_SYS_ADMIN trips up. The only problem is you won't
have the BTF id of the module (which you get from the object), but I
don't currently see that being used anywhere in libbpf. I might be
missing something though.

Alan





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux