netdev - Re: [PATCH v2 bpf-next 10/16] bpf: Add bpf_btf_find_by_name

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210428015554.j7cffimb6lnv3ir7@ast-mbp.dhcp.thefacebook.com>
Date:   Tue, 27 Apr 2021 18:55:54 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH v2 bpf-next 10/16] bpf: Add bpf_btf_find_by_name_kind()
 helper.

On Tue, Apr 27, 2021 at 10:45:38AM -0700, Andrii Nakryiko wrote:
> > >
> > > > + *             If btf_fd is zero look for the name in vmlinux BTF and in module's BTFs.
> > > > + *     Return
> > > > + *             Returns btf_id and btf_obj_fd in lower and upper 32 bits.
> > >
> > > Mention that for vmlinux BTF btf_obj_fd will be zero? Also who "owns"
> > > the FD? If the BPF program doesn't close it, when are they going to be
> > > cleaned up?
> >
> > just like bpf_sys_bpf. Who owns returned FD? The program that called
> > the helper, of course.
> 
> "program" as in the user-space process that did bpf_prog_test_run(),
> right? In the cover letter you mentioned that BPF_PROG_TYPE_SYSCALL
> might be called on syscall entry in the future, for that case there is
> no clear "owning" process, so would be curious to see how that problem
> gets solved.

well, there is always an owner process. When syscall progs is attached
to syscall such FDs will be in the process that doing syscall.
It's kinda 'random', but that's the job of the prog to make 'non random'.
If it's doing syscalls that will install FDs it should have a reason
to do so. Likely there will be limitations on what bpf helpers such syscall
prog can do if it's attached to this or that syscall.
Currently it's test_run only.

I'm not sure whether you're hinting that it all should be FD-less or I'm
putting a question in your mouth, but I've considered doing that and
figured that it's an overkill. It's possible to convert .*bpf.* do deal
with FDs and with some other temporary handle. Instead of map_fd the
loader prog would create a map and get a handle back that it will use
later in prog_load, etc.
But amount of refactoring looks excessive.
The generated loader prog should be correct by construction and
clean up after itself instead of burdening the kernel cleaning
those extra handles.