Bug #2052813 “[MIR] bpfcc” : Bugs : bpfcc package : Ubuntu

Revision history for this message

Mate Kukri (mkukri) wrote on 2024-02-09:

#1

This has some potential issues but I am opening a bug about it to have somewhere to discuss.

Christian Ehrhardt  (paelzer) on 2024-02-13

Changed in bpfcc (Ubuntu):
assignee:	nobody → Christian Ehrhardt  (paelzer)

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-02-20:

#2

Download full text (9.5 KiB)

Review for Source Package: bpfcc

[Summary]
MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

I'm unsure if this needs a security review, I'll be back with an update
on that once I've consulted security.

List of specific binary packages to be promoted to main: libbpfcc

Specific binary packages built, but NOT to be promoted to main: python3-bpfcc,
bpfcc-tools, libbpf-tools, bpfcc-introspection, bpfcc-lua
Those are only excluded for not beeing needed in the dependency chain right now.
They are ok to be promoted later as needed and especially the collection
of tools can be quite handy for users to start with bpf.

Notes:
- #3 I'll need to check with the security team if they think this needs
their review as I'm unsure about that detail.

Required TODOs:
- #1 Please get Doko or Samir to confirm that it is ok in their
  POV to also promote libclang-cpp17 as part of this.
- #5 Please have a look if some of the tests could run at build time (chance is
  low due to the kernel dependency.
- #6 Please do wrap the provided tests/* into an autopkgtest against a system
  and kernel and dependencies of the same release. (more below)
- #7 There is no versioned library package nor symbols tracking. It isn't meant
  to be stable as shown on soname 0.x, but adding this to main means we might
  patch things along the way and some certainty if we by accident break API/ABI
  is a nice feature. Please have a look at adding that, symbols tracking for
  sure and considering proper soname versioned package for the lib at lower
  priority and in sync with Debian later on.
  If you believe symbols tracking isn't the way, have a look at
  abi-compliance-check or abigail or anything else that will solve the same.

Recommended TODOs:
- #2 while none is super critical, the list as of today is still of reasonable
  size. This would be your chance to triage all of the open bugs
  so that you can from now on consider it fully under control with ongoing
  triage when it is added to main.
  So please consider doing a full triage (and fix those worth) run of
  https://bugs.launchpad.net/ubuntu/+source/bpfcc/+bugs

- #4 The package should get a team bug subscriber before being promoted

[Rationale, Duplication and Ownership]
- There is no other package in main providing the same functionality.
  This is not in conclict with libbpf, it is using libbpf to provide
  the next layer of value on top.
  It is somewhat related to gcc-bpf, but libbpfcc is what the ecosystem
  seems to rely on more.
  Further there is overlap with perf-tools-unstable which inspired some
  tools now found here, but perf-tools-unstable is not in main either and
  less maintained these days, hence chosing bpfcc is the right choice AFICS.

- A team is committed to own long term maintenance of this package.
=> Foundations

- The rationale given in the report seems valid and useful for Ubuntu
  BPF use cases are useful in testing and analysis and slowly replace older
  tools by being more efficient or able to do things not possible without BPF.
  This completes the suite of programs and packages aiming for this to b...

Review for Source Package: bpfcc

[Summary]
MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

I'm unsure if this needs a security review, I'll be back with an update
on that once I've consulted security.

List of specific binary packages to be promoted to main: libbpfcc

Specific binary packages built, but NOT to be promoted to main: python3-bpfcc,
bpfcc-tools, libbpf-tools, bpfcc-introspection, bpfcc-lua
Those are only excluded for not beeing needed in the dependency chain right now.
They are ok to be promoted later as needed and especially the collection
of tools can be quite handy for users to start with bpf.

Notes:
- #3 I'll need to check with the security team if they think this needs
  their review as I'm unsure about that detail.

Required TODOs:
- #1 Please get Doko or Samir to confirm that it is ok in their
  POV to also promote libclang-cpp17 as part of this.
- #5 Please have a look if some of the tests could run at build time (chance is
  low due to the kernel dependency.
- #6 Please do wrap the provided tests/* into an autopkgtest against a system
  and kernel and dependencies of the same release. (more below)
- #7 There is no versioned library package nor symbols tracking. It isn't meant
  to be stable as shown on soname 0.x, but adding this to main means we might
  patch things along the way and some certainty if we by accident break API/ABI
  is a nice feature. Please have a look at adding that, symbols tracking for
  sure and considering proper soname versioned package for the lib at lower
  priority and in sync with Debian later on.
  If you believe symbols tracking isn't the way, have a look at
  abi-compliance-check or abigail or anything else that will solve the same.

Recommended TODOs:
- #2 while none is super critical, the list as of today is still of reasonable
  size. This would be your chance to triage all of the open bugs
  so that you can from now on consider it fully under control with ongoing
  triage when it is added to main.
  So please consider doing a full triage (and fix those worth) run of
  https://bugs.launchpad.net/ubuntu/+source/bpfcc/+bugs

- #4 The package should get a team bug subscriber before being promoted

[Rationale, Duplication and Ownership]
- There is no other package in main providing the same functionality.
  This is not in conclict with libbpf, it is using libbpf to provide
  the next layer of value on top.
  It is somewhat related to gcc-bpf, but libbpfcc is what the ecosystem
  seems to rely on more.
  Further there is overlap with perf-tools-unstable which inspired some
  tools now found here, but perf-tools-unstable is not in main either and
  less maintained these days, hence chosing bpfcc is the right choice AFICS.

- A team is committed to own long term maintenance of this package.
  => Foundations

- The rationale given in the report seems valid and useful for Ubuntu
  BPF use cases are useful in testing and analysis and slowly replace older
  tools by being more efficient or able to do things not possible without BPF.
  This completes the suite of programs and packages aiming for this to be
  less hacky and instead more accesible and reliable.

[Dependencies]
OK:
- There is a -dev package, but it does not bring further dependencies and
  therefore needs no auto-exclude
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems:
- other Dependencies to MIR due to this:
  This will also need libclang-cpp17 to be promoted to main.
  The llvm related MIRs are quite old and follow none of todays standards.
  - https://bugs.launchpad.net/ubuntu/+source/llvm/+bug/391375
  - https://bugs.launchpad.net/ubuntu/+source/llvm-2.9/+bug/790204
  Since then things have been carried forward, and as of today in noble
  bin:libclang-cpp17 is from src:llvm-toolchain-17
  Now llvm-toolchain-17 is in main based on the old case, but we did not
  yet clearly state what is and what isn't in scope.
  This should be fine, and gladly the owning team for that is foundations
  as well, so we do not need to convince anyone else to add more.
  But you should get Doko or Samir to please confirm that it is ok in their
  POV to also promote libclang-cpp17 as part of this.

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking (some wrap libs a different way, but not static linking)
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

Problems: None

[Security]
OK:
- history of CVEs does not look concerning
- does not use webkit1,2
- does not use lib*v8 directly
- does not expose any external endpoint (port/socket/... or similar)
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates,
  signing, ...)

Problems:
- does not run a daemon as root (but runs programs in the kernel scope which
  is ... worse ... is it?)
- does not parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source - it parses data from the kernel though which
  might have been tampered. Imagine an attack that can only modify
  an unimportant thing, but then bpf tools read from there and load
  new code based on that. Might be too theoretical, but ... ?!?
- This does not make appropriate (for its exposure) use of established
  risk mitigation features (dropping permissions, using temporary
  environments, restricted users/groups, seccomp, systemd isolation
  features, apparmor, ...).
  Each tool actually has a quite small function and could easily be confined,
  and it runs as root having a lots of power, but then it only handles data
  from the kernel, so what attack would we think of?
- While the history of CVEs does not look concerning (there are plenty with
  BPF but they are kernel CVEs ususally). To load BPF programs you need
  root / CAP_SYS_ADMIN which gives you everything already, so one might argue
  if there is any extra exposure.
  Without root permissions all you can do is have some of the code do a little
  bit to then be denied with some "Operation not permitted" issue.
- One could say you are all safe as you already have the keys to the castle
  if you can use it. But OTOH inserting code into the kernel is quite an
  attack vector to make more possible which otherwise would not be possible.

=> I'm not sure, I think due to and despite all of the above this will not
   need security review, but we said we want to err on the side of caution.
   I'll run this by the team to be sure.

[Common blockers]
OK:
- does not FTBFS currently
- This does not need special HW for build or test
- no new python2 dependency
- includes a Python package, but using dh_python

Problems:
- does not have a test suite that runs at build time
  weirdly the d/rules mentioned dh_auto_test but it isn't seen in the build log
- does have a non-trivial test suite that runs as autopkgtest
  There are tests in tests/* for many subcomponents.
  Those tests are even built.
  But I see no execution of the tests.
  There is ./.github/workflows/bcc-test.yml which outlines automated
  tests on Ubuntu focal so chances are high that things work, but e.g. it
  misses 22.04 or even 24.04 and also llvm newer than v15
  It would bre great to leverage those existing tests to always run the package
  content against the releases default kernel and dependencies.
  The build environment isn't the best for that, but this sounds like a great
  opportunity to spawn a small guest of the same release and run those in there.
  Added to required todo's.

[Packaging red flags]
OK:
- Ubuntu does carry a delta, but it is reasonable and maintenance under
  control
- debian/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
  I'm ok with some overrides for manpages, those that exist are delivered
- debian/rules is rather clean
- It is not on the lto-disabled list

Problems:
- symbols tracking is not in place.
  But then the library isn's yet having a clear soname either, is is on 0.x
  and not meant to be stable.
  There are three consumers so far. bpftrace and golang-github-iovisor-gobpf-dev
  are pretty much developed in sync and there also is the more independent
  oci-seccomp-bpf-hook.
  It is no strict urgent requirement, but should this get versioned lib
  packages and symbol tracking, I think it would help to ensure quality.
  Especially once in main and e.g. a security fix comes in it would help
  to check if by accident we broke API/ABI in any way.
  Adding to required TODOs.

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (this just works different)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside
  tests) => root only execution anyway
- no use of user nobody
- no use of setuid / setgid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no translation present, but none needed for this case (admin/dev only)

Problems: None

Changed in bpfcc (Ubuntu):
status:	New → Incomplete
assignee:	Christian Ehrhardt  (paelzer) → Mate Kukri (mkukri)

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-02-20:

#3

We discussed the need or lack of need for security review here.

[16:38] <sarnold> I'm not sure either; on the one hand, administrative privilege is required to run these, so there's a thin barrier at best
[16:38] <sarnold> most of the security layer happens in the kernel
[16:39] <sarnold> I believe that this package itself is very little risk to the security team, but the kernel portion might -- so, I'm inclined to say that this doesn't need security team review
[16:39] <eslerm> a quick review might remove some footguns
[16:40] <cpaelzer> eslerm: is there a good way to express "we should have a quick check but not a full review"
[16:41] <cpaelzer> how about you volunteer for that "quick but not full" check
[16:41] <cpaelzer> then the solution is that I'll assign you
[16:41] <cpaelzer> actually it is back with mkukri so I'd subscribe you
[16:41] <eslerm> a short audit might find something useful to report upstream, it might just be bugs, if the security context cannot be made worse by bugs
[16:42] <eslerm> I can do that
[16:42] <cpaelzer> thank you

Revision history for this message

Steve Langasek (vorlon) wrote on 2024-02-26:

#4

llvm-toolchain-17 is in main and there's nothing special about its libraries for MIR. This is an ordinary binary promotion.

Mark Esler (eslerm) on 2024-02-26

tags:

added: sec-3897

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-02-26:

#5

> llvm-toolchain-17 is in main and there's nothing special about its libraries for MIR. This is an ordinary binary promotion.

Perfectly fine with me, thanks for confirming.
One less detail to think about.

Revision history for this message

Mate Kukri (mkukri) wrote on 2024-02-27:

#6

1-0.29.1+ds-1ubuntu3.diff Edit (1.4 KiB, text/plain)

#2 i had a look through the bug tracker, but some of the bugs are rather difficult to triage given that they reference years old Ubuntu releases

#5 some probably could, but I don't have the understanding needed of the BPF ecosystem to pull this off

#6 see attached patch for this, unfortunately some of these tests do still fail currently

#7 unfortunately this seems rather difficult to do as libbpfcc seem to export a large number of c++ symbols

Changed in bpfcc (Ubuntu):
status:	Incomplete → Opinion
status:	Opinion → In Progress
assignee:	Mate Kukri (mkukri) → nobody

Revision history for this message

Seth Arnold (seth-arnold) wrote on 2024-02-27:

#7

> Specific binary packages built, but NOT to be promoted to main: python3-bpfcc,
> bpfcc-tools, [...]

I would have thought that getting these tools would have been the entire point of this MIR. There's an immense amount of value built in them, and without the tools we've got the framework but no pre-built way to consume it. These pre-built tools are 99% of why I want this package promoted.

(A similar question was raised for the bpftrace package -- we might as well just stop reviewing these packages if we remove the actual tools from the packages.)

What's the rationale for not promoting the tools?

Thanks

Revision history for this message

Mate Kukri (mkukri) wrote on 2024-02-27:

#8

I believe we do want to promote bpfcc-tools as well, at least that binary name was mentioned before, but this package is also needed as a dependency for bpftrace too.

Revision history for this message

Mark Esler (eslerm) wrote on 2024-02-27 (last edit on 2024-02-27):

#9

Promoting bpfcc-tools and bpftrace is driving promotion of bpfcc based on FO147.

Also, bpftrace's /usr/sbin/*.bt files re-implement bpfcc-tools with bpftrace.

Assigning to Security for MIR, with root-use scope kept in mind. Only code for libbpfcc and bpfcc-tools will be reviewed.

Changed in bpfcc (Ubuntu):
assignee:	nobody → Ubuntu Security Team (ubuntu-security)

Revision history for this message

Mark Esler (eslerm) wrote on 2024-02-28:

#10

Máté, could you please see if the rational can be broadened for FO147?

I suspect that libbpf-tools is also important.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-02-28: Re: [Bug 2052813] Re: [MIR] bpfcc

#11

On Wed, Feb 28, 2024 at 5:00 AM Mark Esler <email address hidden> wrote:
>
> Máté, could you please see if the rationale can be broadened for FO147?
> I suspect that libbpf-tools is also important.

As far as I can see it is even the same functionality and the same
code, just built differently to work with less dependencies.
So a review of quality and maintainability of the source should cover
both anyway (with the difference being in the build instructions).

Revision history for this message

Mark Esler (eslerm) wrote on 2024-02-28:

#12

Some of the bpf tools do not work on mantic.

e.g. `/usr/sbin/tcptop-bpfcc` from `bpfcc-tools` does not work, but `/usr/sbin/tcptop` from `libbpfcc` does (on mantic)

Kernel configs and pahole version used to build mantic's kernel should be okay https://github.com/iovisor/bcc/tree/master/libbpf-tools ?

Revision history for this message

Mate Kukri (mkukri) wrote on 2024-03-07:

#13

1-0.29.1+ds-1ubuntu4.diff Edit (6.3 KiB, text/plain)

This should bring some working autopkgtests to this package by disabling a set of failing tests.

Revision history for this message

Mate Kukri (mkukri) wrote on 2024-03-15:

#14

2-0.29.1+ds-1ubuntu4.diff Edit (6.6 KiB, text/plain)

Added DEP3 header

Revision history for this message

Mark Esler (eslerm) wrote on 2024-03-15:

#15

Download full text (3.3 KiB)

I reviewed bpfcc 0.29.1+ds-1ubuntu2 as checked into noble. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

- CVE History
  - no CVEs tracked in UCT, initially
  - searching for "bcc" CVEs finds false-positives
- Build-Depends
  - nothing concerning
- pre/post inst/rm scripts
  - typical dh_python3 for python3-bpfcc
- init scripts
  - none
- systemd units
  - none
- dbus services
  - none
- setuid binaries
  - none
- binaries in PATH
  - numerous. +220.
- sudo fragments
  - none
- polkit files
  - none
- udev rules
  - none
- unit tests / autopkgtests
  - some added
- cron jobs
  - none
- Build logs
  - hardening-no-pie is not a concern in this case
  - manual page warnings
  - W: libbpfcc: package-name-doesnt-match-sonames libbcc-bpf0 libbcc0

- Processes spawned
  - popen use looks okay
  - system("clear") is fine
  - memleak.c uses fork, etc
- Memory management
  - extremely heavy use
  - in context, I am not concerned with occult practices in this package
- File IO
  - heavy use
- Logging
  - extremely heavy use
- Environment variable usage
  - none
- Use of privileged functions
  - Security's MIR tooling finds many false-positives
  - vmlinux headers are fine
- Use of cryptography / random number sources etc
  - none
  - vminux*.h sets certificate configs
- Use of temp files
  - tmp race conditions possibly allow unauthenticated users to control unpacked kernel headers
    - Resolved quickly by upstream! CVE-2024-2314
    - see related issue in bpftrace MIR (LP#2052809)
- Use of networking
  - heavy use
- Use of WebKit
  - none
- Use of PolicyKit
  - none

- Any significant cppcheck and Covreity results
  - bugs found (memory leaks etc), but not concerned about these being vulnerabilities in context
  - parsing untrusted data (e.g., network traffic) could possibly lead to exploitation
  - coverity.txt attached
- Any significant shellcheck results
  - not concerning
- Any significant bandit results
  - none
  - subprocess calls cannot be controlled without root access
- Any significant govulncheck results
  - none
- Any significant Semgrep results
  - none
  - complaints about system() and strtok excused in context

There is 986,872 loc. Security's review is limited.

As with bpftrace, these are admin tools which require root access. It is unlikely that most bugs in bpfcc would cause a loss of security and become a vulnerability; root already has control. Parsing untrusted data with a root process can lead to trouble. This review expects that developers will want to use these tools and that system administrators will make wise choices.

Some binaries do not work out of box. This needs testings. e.g., /usr/sbin/tcptop-bpfcc from bpfcc-tools does not work, but /usr/sbin/tcptop from libbpfcc does.

Binaries from bpfcc-tools, libbpfcc, and bpftrace have redundant functions. Please consider which binaries should be made default. In particular, most bpftrace binaries are merely examples.

The bcc snap is published by Canonical and should be updated. See ./snap/README.md

Upstream was extraordinarily quick at addressing a potential security issue which was reported to them \o/
- CVE-2024-2314

Security t...

I reviewed bpfcc 0.29.1+ds-1ubuntu2 as checked into noble.  This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

- CVE History
  - no CVEs tracked in UCT, initially
  - searching for "bcc" CVEs finds false-positives
- Build-Depends
  - nothing concerning
- pre/post inst/rm scripts
  - typical dh_python3 for python3-bpfcc
- init scripts
  - none
- systemd units
  - none
- dbus services
  - none
- setuid binaries
  - none
- binaries in PATH
  - numerous. +220.
- sudo fragments
  - none
- polkit files
  - none
- udev rules
  - none
- unit tests / autopkgtests
  - some added
- cron jobs
  - none
- Build logs
  - hardening-no-pie is not a concern in this case
  - manual page warnings
  - W: libbpfcc: package-name-doesnt-match-sonames libbcc-bpf0 libbcc0

- Processes spawned
  - popen use looks okay
  - system("clear") is fine
  - memleak.c uses fork, etc
- Memory management
  - extremely heavy use
  - in context, I am not concerned with occult practices in this package
- File IO
  - heavy use
- Logging
  - extremely heavy use
- Environment variable usage
  - none
- Use of privileged functions
  - Security's MIR tooling finds many false-positives
  - vmlinux headers are fine
- Use of cryptography / random number sources etc
  - none
  - vminux*.h sets certificate configs
- Use of temp files
  - tmp race conditions possibly allow unauthenticated users to control unpacked kernel headers
    - Resolved quickly by upstream! CVE-2024-2314
    - see related issue in bpftrace MIR (LP#2052809)
- Use of networking
  - heavy use
- Use of WebKit
  - none
- Use of PolicyKit
  - none

- Any significant cppcheck and Covreity results
  - bugs found (memory leaks etc), but not concerned about these being vulnerabilities in context
  - parsing untrusted data (e.g., network traffic) could possibly lead to exploitation
  - coverity.txt attached
- Any significant shellcheck results
  - not concerning
- Any significant bandit results
  - none
  - subprocess calls cannot be controlled without root access
- Any significant govulncheck results
  - none
- Any significant Semgrep results
  - none
  - complaints about system() and strtok excused in context

There is 986,872 loc. Security's review is limited.

As with bpftrace, these are admin tools which require root access. It is unlikely that most bugs in bpfcc would cause a loss of security and become a vulnerability; root already has control. Parsing untrusted data with a root process can lead to trouble. This review expects that developers will want to use these tools and that system administrators will make wise choices.

Some binaries do not work out of box. This needs testings. e.g., /usr/sbin/tcptop-bpfcc from bpfcc-tools does not work, but /usr/sbin/tcptop from libbpfcc does.

Binaries from bpfcc-tools, libbpfcc, and bpftrace have redundant functions. Please consider which binaries should be made default. In particular, most bpftrace binaries are merely examples.

The bcc snap is published by Canonical and should be updated. See ./snap/README.md

Upstream was extraordinarily quick at addressing a potential security issue which was reported to them \o/
 - CVE-2024-2314

Security team ACK for promoting bpfcc to main. Note that Security's ACK is for all packages generated by the bpfcc source package, the MIR Team's ACK may only be for a subset of binary packages.

Changed in bpfcc (Ubuntu):
assignee:	Ubuntu Security Team (ubuntu-security) → nobody

Revision history for this message

Lukas Märdian (slyon) wrote on 2024-04-02:

#16

Security review OK (comment #15). I subscribed ~foundations-bugs.

Issue #1 confirmed in comment #4 (and now upgraded to LLVM-18 by doko)
Issue #5 probably not possible due to kernel dependency
Issue #6 autopkgtests sponsored: https://launchpad.net/ubuntu/+source/bpfcc/0.29.1+ds-1ubuntu6

Issue #7 still open, consider using something like c++filt, https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries

Changed in bpfcc (Ubuntu):
status:	In Progress → Incomplete

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-04-02:

#17

Thank you for adding all the QA and clarifying more.

When you change dependencies to pull this in (I see Ubuntu-meta already did change).

This is trying to get the value to the users, but not clutter where possible.
I think we should depend on libbpf-tools instead of the current bpfcc-tools.

WDYT? Could we do that change before doing promotions?

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-04-02:

#18

I'll not mark it "in progress" yet waiting for the "which -tools" to use.
But it would be ready once you settled.

Revision history for this message

Robie Basak (racb) wrote on 2024-04-03:

#19

The main user story being implemented here is the one specified by Brendan Gregg in his literature, including his book "Systems Performance, 2nd Edition". In that book he specifies "Linux crisis tool packages" [Table 4.1], which specifies bpfcc-tools and a bunch of binaries provided by that.

Looking at the difference between libbpf-tools and bpfcc-tools, the former is only a subset and doesn't include all the tools specified in the book. For example, the book covers trace and argdist in section 15.1.6. These have -bpfcc versions provided by bpfcc-tools, but I don't see any equivalents in libbpf-tools.

The intention is that we install by default what the book covers. Therefore, I'd like to request (at least initially) that we have bpfcc-tools in main. If that's not possible then libbpf-tools will be better than nothing, but will add to the caveats in this entire effort.

Please could you consider the MIR request to be for the bpfcc-tools binary package?

Revision history for this message

Robie Basak (racb) wrote on 2024-04-03:

#20

> [Rationale]
> - The package bpfcc is required in Ubuntu main as a runtime dependency of
> bpftrace.

Correction: this is true, but we'd also like bpfcc-tools in its own right since these tools are recommended by experts for direct use.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-04-04:

#21

Thank you for the check and explanation.

While that is sad for size (80m vs 20m) it makes sense for the purpose.
And this isn't in minimal so it seems sort of ok to me.

Trying to unblock things this seems ready now.

Changed in bpfcc (Ubuntu):
status:	Incomplete → In Progress
status:	In Progress → Fix Committed

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-04-04:

#22

Dependency is shown in mismatches, setting to Fix Committed.

I thought in the current situation we'd need to promote all (-release, -updates, -proposed), but on bpftrace only -release was moved. Let me check on that before that might interfere with the current archive activities.

If anyone else comes by knowing for sure, this can be promoted (src:bpfcc bin:libbpfcc bin:python3-bpfcc bin:bpfcc-tools).

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2024-04-04:

#23

Download full text (4.8 KiB)

Clarified, moving -release and -proposed as -updates will be deleted anyway

Also libbpfcc-dev is an auto-include and has no weird dependencies that make us need to exclude it.

Override component to main
bpfcc 0.29.1+ds-1ubuntu4 in noble: universe/misc -> main
Override [y|N]? y
1 publication overridden.

Override component to main
bpfcc 0.29.1+ds-1ubuntu6 in noble: universe/misc -> main
Override [y|N]? y
1 publication overridden.

Override component to main
libbpfcc 0.29.1+ds-1ubuntu4 in noble arm64: universe/misc/optional/100% -> main
libbpfcc 0.29.1+ds-1ubuntu4 in noble armhf: universe/misc/optional/100% -> main
libbpfcc 0.29.1+ds-1ubuntu4 in noble ppc64el: universe/misc/optional/100% -> main
libbpfcc 0.29.1+ds-1ubuntu4 in noble riscv64: universe/misc/optional/100% -> main
libbpfcc 0.29.1+ds-1ubuntu4 in noble s390x: universe/misc/optional/100% -> main
python3-bpfcc 0.29.1+ds-1ubuntu4 in noble amd64: universe/python/optional/100% -> main
python3-bpfcc 0.29.1+ds-1ubuntu4 in noble arm64: universe/python/optional/100% -> main
python3-bpfcc 0.29.1+ds-1ubuntu4 in noble armhf: universe/python/optional/100% -> main
python3-bpfcc 0.29.1+ds-1ubuntu4 in noble i386: universe/python/optional/100% -> main
python3-bpfcc 0.29.1+ds-1ubuntu4 in noble ppc64el: universe/python/optional/100% -> main
python3-bpfcc 0.29.1+ds-1ubuntu4 in noble riscv64: universe/python/optional/100% -> main
python3-bpfcc 0.29.1+ds-1ubuntu4 in noble s390x: universe/python/optional/100% -> main
bpfcc-tools 0.29.1+ds-1ubuntu4 in noble amd64: universe/misc/optional/100% -> main
bpfcc-tools 0.29.1+ds-1ubuntu4 in noble arm64: universe/misc/optional/100% -> main
bpfcc-tools 0.29.1+ds-1ubuntu4 in noble armhf: universe/misc/optional/100% -> main
bpfcc-tools 0.29.1+ds-1ubuntu4 in noble i386: universe/misc/optional/100% -> main
bpfcc-tools 0.29.1+ds-1ubuntu4 in noble ppc64el: universe/misc/optional/100% -> main
bpfcc-tools 0.29.1+ds-1ubuntu4 in noble riscv64: universe/misc/optional/100% -> main
bpfcc-tools 0.29.1+ds-1ubuntu4 in noble s390x: universe/misc/optional/100% -> main
libbpfcc-dev 0.29.1+ds-1ubuntu4 in noble arm64: universe/libdevel/optional/100% -> main
libbpfcc-dev 0.29.1+ds-1ubuntu4 in noble armhf: universe/libdevel/optional/100% -> main
libbpfcc-dev 0.29.1+ds-1ubuntu4 in noble ppc64el: universe/libdevel/optional/100% -> main
libbpfcc-dev 0.29.1+ds-1ubuntu4 in noble riscv64: universe/libdevel/optional/100% -> main
libbpfcc-dev 0.29.1+ds-1ubuntu4 in noble s390x: universe/libdevel/optional/100% -> main
Override [y|N]? y
24 publications overridden.

Override component to main
libbpfcc 0.29.1+ds-1ubuntu6 in noble amd64: universe/misc/optional/100% -> main
libbpfcc 0.29.1+ds-1ubuntu6 in noble arm64: universe/misc/optional/100% -> main
libbpfcc 0.29.1+ds-1ubuntu6 in noble armhf: universe/misc/optional/100% -> main
libbpfcc 0.29.1+ds-1ubuntu6 in noble ppc64el: universe/misc/optional/100% -> main
libbpfcc 0.29.1+ds-1ubuntu6 in noble riscv64: universe/misc/optional/100% -> main
libbpfcc 0.29.1+ds-1ubuntu6 in noble s390x: universe/misc/optional/100% -> main
python3-bpfcc 0.29.1+ds-1ubuntu6 in noble amd64: universe/python/optional/100% -> main
python3-bpfcc 0.29.1+ds-1ubuntu6 in noble arm64:...

Ubuntu
bpfcc package

[MIR] bpfcc

Bug Description

CVE References

Other bug subscribers

Patches

Remote bug watches

Changed in bpfcc (Ubuntu):
status:	Fix Committed → Fix Released

Ubuntubpfcc package

[MIR] bpfcc

Bug Description

CVE References

Other bug subscribers

Patches

Remote bug watches

Ubuntu
bpfcc package