ebpf-digest

cilium/ebpf v0.10.0 - BTF Marshaling

release ·

We’re pleased to announce the first ebpf-go release of 2023! There is one breaking change, so please read through the release notes carefully. All users are encouraged to upgrade.

Breaking Changes

Support for BTF marshaling

So far, the library would only load BTF into the kernel that was originally generated by clang or pahole. As of this release, the library will instead marshal btf.Types directly into BTF blobs. For example, it’s now possible to create an ebpf.Map from Go code by populating the MapSpec.Key and .Value fields with the map’s k/v types to make bpftool map dump nicely pretty-print its contents for you.

As expected, there are a few important side effects and breaking changes to be aware of:

We’re interested in hearing your use cases for explicitly disabling BTF during map/prog loads. We hope the need for disabling BTF altogether should arise less frequently, given the library falls back gracefully when the underlying kernel doesn’t support BTF. In case you do believe this to be necessary, please raise an issue to discuss this further.

Fixes

NewProgram returns an unwrapped VerifierError

Since commit 148c76cf32ddb279 (“internal: make VerifierError more succinct”) the library has defaulted to omitting most of the verifier log when loading a program failed. The intention was that callers would use formatting with the %+v verb to output as much context as necessary. Due to how error wrapping with fmt.Errorf works this meant that the error had to be unwrapped with errors.As, which led to confusion.

NewProgram and friends now return an unwrapped VerifierError so that callers can format the error more easily.

Reliable VerifierError.Truncate field

Prior to this release, the VerifierError.Truncate field would only be set in case ProgramOptions.LogLevel was left to the default value of 0, among a few other quirks. This has now been resolved, making the VerifierError.Truncate field a reliable driver for a retry loop that automatically grows the verifier log buffer and retries loading the program(s). See https://github.com/cilium/cilium/pull/21973/commits/934bccff82f833dcc532f436b4fb419c5d89cb96 for an example implementation.

Additions

Expanded and overhauled feature probes

features.HaveProgramType() can now conclusively probe for the program types ebpf.LSM, ebpf.Tracing and ebpf.Extension without relying on recognizing specific error return values.

Package features has been refactored to use internal.FeatureTest, unifying error wrapping and result caching with the library’s internal machinery. ErrNotSupported returned from features now includes the minimum required kernel version and a feature name.

Kretprobes allow setting maxactive

The kernel’s kretprobe implementation has a limitation where only a fixed number of concurrent calls to a probed function are handled. Usually the kernel chooses a sufficient default value, but for very busy functions this default is too low. This leads to missed kretprobe events.

There is an (unfortunate) workaround for this: the user can specify how many concurrent calls they want to support via a maxactive parameter. This comes with a lot of drawbacks however. maxactive is only supported when using an obsolete interface to kretprobes, and it’s not at all clear how to arrive at the correct maxactive setting. link.KprobeOptions now exposes this setting to the user, since it is the only partial fix.

The authors of the library recommend to not use maxactive unless absolutely necessary. Incorrect use will make your application more brittle and may have system-wide performance impact.

What’s Changed

New Contributors

Full Changelog: https://github.com/cilium/ebpf/compare/v0.9.3...v0.10.0

View source