Upgrade Cilium's eBPF library version to 0.16

[rafaelroquetto]

Upgrade the cilium version to 0.16 (latest). There are many important fixes in between (e.g. cilium/ebpf#1348) that would be nice to have downstream.

This PR basically updates the version of the cilium package and its dependencies, and fixes libcontainer/cgroups/devices/ebpf_linux.go to reflext the new API.

Disclaimer: I am not well acquainted with the codebase, so apologies in advance for anything stupid I may be doing.

Resolves: #4396

[AkihiroSuda]

Upgrade Cilium version to 0.16

s/Cilium/Cilium's eBPF library/

[rafaelroquetto]

I've pushed two different commits to illustrate the points being discussed, but if everything is accepted, I intend to squash-merge them as a single commit (happy to amend the PR for that).

[rata]

@rafaelroquetto how is this solving a bug? You use the libcontainer module in your program and can't update the cilium dep to that version there due to runc using the old one? Or can you clarify that?

If that is the case, too bad cilium doesn't provide a 1.x release :(

[rata]

why not adding the flag too, as it was done before?

[rafaelroquetto]

They are now handled by the underlying code and are no longer explicitly allowed. See https://github.com/cilium/ebpf/blob/15d4f245e548eb00383aa88a24da934f0d26fc43/link/program.go#L34

[rata]

Thanks. For the next time, pointing this out in the commit/PR makes the review simpler :)

[rafaelroquetto]

@rata you're spont on! We have a situation in which one of our projects (Grafana Beyla) requires fixes from more recent Cilium's eBPF releases (notoriously cilium/ebpf#1348). We then have another project, Grafana Alloy, which depends both on Beyla and runc, and as you correctly guessed, we can't update the cilium dependency. :(

[rafaelroquetto]

(@wildum can perhaps offer further context)

[wildum]

That's correct, and on a more generic case, I expect all projects that have a dependency to github.com/opencontainers/runc and to cilium/ebpf won't be able to upgrade their cilium/ebpf dependency to the latest release that contains the fix mentioned above.
That's why this upgrade is quite important.

[kolyshkin]

The breaking change is from cilium/ebpf#1163 and it first appeared in v0.13.0 (which is probably the reason why dependabot never opened a PR to upgrade it).

@cyphar PTAL

[AkihiroSuda]

Please squash commits

[rafaelroquetto]

@AkihiroSuda done

[kolyshkin]

@rafaelroquetto due to #4393 merge (which vendored golang.org/x/sys) this needs a rebase.

[rafaelroquetto]

@kolyshkin done - interestingly it no longer complains and requires the change from go 1.22 => go 1.22.0.

Thank you all again for taking time to review this.

[kolyshkin]

LGTM; thanks!

[dims]

@kolyshkin @AkihiroSuda would this PR qualify to be cherry-picked on the 1.1 branch? would love to pay down some debt in kubernetes/kubernetes w.r.t dependencies if we can move up to newer cilium

[AkihiroSuda]

Yes, feel free to submit a cherrypick PR

[kolyshkin]

@kolyshkin @AkihiroSuda would this PR qualify to be cherry-picked on the 1.1 branch? would love to pay down some debt in kubernetes/kubernetes w.r.t dependencies if we can move up to newer cilium

1.1 still uses go 1.18, so that would not be simple.

As of today, I'd rather release 1.2.0-final out the door (and use it in k8s).

[dims]

As of today, I'd rather release 1.2.0-final out the door (and use it in k8s).

@kolyshkin that sounds awesome!

[cyphar]

It seems that this caused a regression of #3008 because while cilium/ebpf@417f8a2 was handled for the actual implementation of loadAttachCgroupDeviceFilter it seems that we forgot to update the sync.Once check to not use BPF_F_REPLACE.