On Thu, Apr 20, 2023 at 7:46 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: > > >> >> > > > > By switching up actual libbpf used to compile with bpftool, you are > >> >> > > > > potentially introducing subtle problems that your users will be quite > >> >> > > > > unhappy about, if they run into them. Let's work together to make it > >> >> > > > > easier for you to package bpftool properly. We can't switch bpftool to > >> >> > > > > reliably use system-wide libbpf (either static or shared, doesn't > >> >> > > > > matter) because of dependency on internal functionality. > >> >> > > > > > >> >> > > > > > >> >> > > > > [0] https://github.com/libbpf/veristat/releases/tag/v0.1 > >> >> > > > > >> >> > > > So how many copies of libbpf do I need for having a CO-RE toolchain? > >> >> > > > >> >> > > What do you mean by "CO-RE toolchain"? bpftool, veristat, retsnoop, > >> >> > > etc are tools. The fact they are using statically linked libbpf > >> >> > > through Git submodule is irrelevant to end users. You need one libbpf > >> >> > > in the system (for those who link dynamically against libbpf), the > >> >> > > rest are just tools. > >> >> > > > >> >> > > > > >> >> > > > Will different tools have different view of the kernel because they each > >> >> > > > use different private copy of libbpf with different features? > >> >> > > > >> >> > > That's up to tools, not libbpf. You are over pivoting on libbpf here. > >> >> > > There is one view of the kernel, it depends on what features the > >> >> > > kernel supports. If the tool requires some specific functionality of > >> >> > > libbpf, it will update its Git submodule reference to get a version of > >> >> > > libbpf that provides that feature. That's the point, an > >> >> > > application/tool is in control of what kind of features it gets from > >> >> > > libbpf. > >> >> > >> >> Since libbpf has a stable API & ABI, is it theoretically possible for > >> >> bpftool, veristat, retsnoop, etc. all share the same version of libbpf? > >> > > >> > No, because libbpf is not just a set of APIs. Newer libbpf versions > >> > support more BPF-side features, more kernel features, etc, etc. Libbpf > >> > is not a typical user-space library, it is a BPF loader, and even if > >> > user-visible API doesn't change, libbpf's support for various BPF-side > >> > features is extended. Which is important for tools like bpftool, > >> > retsnoop, veristat which rely on loading and working with BPF object > >> > files. > >> > >> The converse of this is also true: if your system is upgraded to a new > >> kernel version with new BPF features, the libbpf version should follow > >> it, and all applications linked against it will automatically take > >> advantage of any bugfixes regardless without having to wait for each > >> application to be updated. > > > > No, if my application was not developed to take advantage of a new > > kernel feature, newer libbpf will do nothing for me. If my application > > wants to support that feature, I'll update my application and > > correspondingly update libbpf embedded in it. If my application is > > affected by some bug fix, I'll update libbpf even faster than distros > > will get to it. > > You may do that, but you're also someone who is following the > development of libbpf closely and pay attention to when bugs appear. Not > all applications developers have the same vigilance for all the > libraries they rely on. Which is the reason distros generally take on > the responsibility of ensuring their users receive timely library > updates. The discussion was about bpftool, veristat, and retsnoop. "You may do that" applies to all of them. I'm not forcing anyone else to follow the same approach (e.g., I'm not forcing perf to vendor libbpf, for example), I'm just opposing someone else forcing us (bpftool, veristat, retsnoop) to not vendor libbpf. > > > I've heard all such arguments over the last few years. They are not > > convincing and my own practical experience shows irrelevance of the > > above argument. > > I don't doubt your personal experience, I'm just objecting to you > dismissing other points of view just because you haven't experienced > them yourself. I acknowledged the security argument. And disagreeing and dismissing are two big differences. So yes, I don't think the security argument outweighs all the downsides of not controlling the exact libbpf version my application relies on. And specifically for libbpf-related use cases, libbpf-using applications are running under root. They are not supposed to accept untrusted ELF files. So even if there is some bug leading to crashes or some malfunction, I don't buy the "emergency, we need to update all libbpf-using apps ASAP" argument, sorry. > > >> Libbpf is really no different from any other library here, and I really > >> don't get why you keep insisting it's "special"... > > > > It's special in the sense that it provides two sets of APIs -- for > > user-space (typical libraries) and BPF object files. Besides that, for > > BPF-side it's not even a set of APIs (headers, helpers, etc), it also > > provides some set of functionality that can improve or be extended > > over time. E.g., libbpf used to not support non-inlined BPF > > subprograms, and then it started supporting them. In terms of API/ABI > > -- nothing changed. Yet the change is very important. > > Lots of libraries do that. File format libraries support new format > features without changing their API, networking libraries support new > protocol features, etc. So again, libbpf is not special in this > respect. I didn't mean to start a "which library is the most special" contest. The original point was about libbpf 1.0 stability of API, and that was my objection, because it's not just about available APIs and their stability. And libbpf is not used for the sake of using libbpf, it is used with (usually embedded) BPF object file(s) that application is expected to work, including any new SEC() support, global variables, etc, etc. > > > Now, I build a tool that is using libbpf and some BPF functionality, > > e.g., retsnoop. Libbpf just got SEC("ksyscall") support. Retsnoop > > wants to take advantage of it. I just go and use SEC("ksyscall") > > programs in .bpf.c files that are embedded inside retsnoop. > > I don't have to *and don't want to* do feature detection of whether a > > particular libbpf version that happens to be installed/packaged on the > > system supports this version. I *know* it does, because I control it, > > through a submodule. That's what I care about. > > Right, so just require a minimum version of the library where the API > you want to use is available. That is pretty standard and distros deal > with this all the time. This is not an argument for static linking or > vendoring... bpftool can't do that due to use of internal APIs. For others (retsnoop, veristat), I don't want to be restricted by the released libbpf version, or by expecting that the target system has new enough libbpf installed. > > > Whether some distro insists on libbpf being shared across any > > libbpf-using application or not is none of my concern. Libbpf is an > > implementation detail of my application (retsnoop), it's not for the > > packager to decide how I develop and structure my tool. > > Right, well, you don't *have* to be cooperative with the wider > ecosystem, of course. Just as packagers don't have to follow your > recommendations if they have good reasons not to. I believe we've had > this discussion before, and I don't think we're going to agree this time > around either, so let's not waste any more virtual ink on rehashing it :) Exactly, so I'm not sure why we are even having this conversation all over again. I agree on not wasting virtual ink anymore. I'm not forcing anyone to follow my advice, I expect others to not force me to follow theirs. > > -Toke >
