proposals/20251215-legacy-bpf-grpc-output-gvisor-engine-deprecation.md
This proposal aims to formalize motivations and procedures for deprecating the legacy eBPF probe, the gRPC output and the gVisor libscap engine.
One of the key objectives of Falco is to maintain a seamless user experience, regardless of the system call event source actually used. This objective imposes strong requirements among all drivers and engines acting as system call source (i.e.: gVisor libscap engine), feature parity, among each other, above all. Feature parity raises challenges from both technical and maintainability perspectives, and these challenges are not justified if the driver/engine is no/little used. For these reasons, this document aims for raising consensus regarding the legacy eBPF probe and gRPC output deprecation.
Similar arguments could be raised in favor of the gRPC output deprecation: this output requires dependency on the gRPC framework, that introduces a non-negligible build time overhead and maintainability burden (especially in a C++ codebase), not justified by the little usage of the output.
Upcoming evidences of non-negligible use of the gVisor engine and the gRPC output could be addressed by providing a separate source plugin in case of gVisor, and a Falco Sidekick output as a replacement of the gRPC output.
The following matrix details the current minimum kernel version officially supported by each driver, for each architecture:
| Kernel module | legacy eBPF probe | Modern eBPF probe | Status | |
|---|---|---|---|---|
| x86_64 | >= 3.10 | >= 4.14 | >= 5.8 | STABLE |
| aarch64 | >= 3.16 | >= 4.17 | >= 5.8 | STABLE |
| s390x | >= 3.10 | >= 5.5 | >= 5.8 | EXPERIMENTAL |
| riscv64 | >= 5.0 | N/A | N/A | EXPERIMENTAL |
| ppc64le | >= 3.10 | >= 5.1 | >= 5.8 | STABLE |
The legacy eBPF probe strives to provide a little more coverage than the modern eBPF one. This increased coverage comes at cost of flexibility and maintainability. Indeed:
Besides the above, the legacy eBPF probe provides support for a range of versions that is entirely contained by the
kernel module supported range. Additionally, different distro kernel flavors already back-port features required by the
modern eBPF, enabling its usage on kernel older than 5.8.
The above considerations, together with the evidence of its little usage, make the legacy eBPF probe a good candidate for deprecation.
gVisor libscap engine implements a system call event source by leveraging events coming from gVisor itself through gRPC.
There is evidence that this engine is little used. Moreover, gVisor doesn't provide all information required to build
all supported event types, indeed resulting in a system call source not completely equivalent to the ones provided by
drivers. Finally, it requires falcosecurity/libs being dependent on protobuf, this latter introducing a non-negligible
build time overhead and maintainability burden.
Deprecating it would allow to streamline system call event sources alignment, maintainability, and reduce build time for
both falcosecurity/falco and falcosecurity/libs.
The gRPC output provides a mechanism through which a gRPC client can subscribe to the Falco alerts stream. This output leverages a gRPC server embedded into Falco.
As for the legacy eBPF probe and the gVisor libscap engine, there is evidence that this output is little used. Also, similarly to the gVisor libscap engine, this requires Falco being dependent on the protobuf, and additionally, on the entire C++ gRPC framework. Finally, the little amount of data that is sent through the gRPC stream, and the communication model (only involving a one-way communication from the server to the client) doesn't justify the need of using gRPC.
Deprecating it would allow to reduce the build system, streamline maintainability, and reduce build time for
falcosecurity/falco.
This section aims to detail the plan to follow contextually and after the deprecation mark, but before taking any definitive removal decision about the legacy eBPF probe, the gVisor libscap engine, and the gRPC output (collectively referred to hereinafter as "the components" or simply "components").
The deprecation of these components introduces user-facing changes that must be addressed as prescribed by the current deprecation policy for "non-backward compatible user-facing changes" (see 20231220-features-adoption-and-deprecation.md#deprecation-policy).
All components are stable, and given that the current stable Falco version is 0.43.0 (ante 1.0.0), the minimum
deprecation period length is 1 release: this means that components cannot be removed before Falco 0.44.0.
At high level, the action plan is to inform users, during the deprecation period, about the deprecation: this is achieved by emitting a deprecation notice if the user try to leverage any of the feature exposed by any component, and by updating the website in any of the relevant areas.
During the deprecation period, but before taking decision to remove the components, projects belonging to the
falcosecurity organization will be updated to not use/rely on any of these. Specifically:
falcosecurity/libs, any CI job building and testing the legacy eBPF probe will be removedfalcosecurity/kernel-testing, playbooks will not build and test the legacy eBPF probe anymorefalcosecurity/event-generator, the internal gRPC alert retriever will be replaced with an HTTP alert retriever,
leveraging the existing HTTP output.This proposal does not address any design or implementation aspect of the gVisor engine and gRPC output replacement, nor formalizes in any way the conditions under which a replacement should be delivered. Upcoming evidences of non-negligible use of the gVisor engine and the gRPC output may be addressed by providing a separate source plugin in case of gVisor, and a Falco Sidekick output as a replacement of the gRPC output, but these latter possibilities should be intended as suggestions, and will not constraint in any way any related future choice.
Finally, this proposal doesn't detail any aspect of the eventual removal.