fix(proposals): specify correct stable falco version

Updated the stable Falco version from 0.43.0 to 0.42.1 in the deprecation policy section.

Signed-off-by: Leonardo Di Giovanna <41296180+ekoops@users.noreply.github.com>

RELEASE.md

@@ -87,10 +87,10 @@ Before proceeding with the release, make sure to complete the following preparat
 - Double-check, by using the following filters, if there is any closed issue/merge PR with no milestone assigned:
   - `is:issue state:closed no:milestone closed:>YYYY-MM-DD`
     [filter](https://github.com/falcosecurity/falco/issues?q=is%3Aissue%20state%3Aclosed%20no%3Amilestone%20closed%3A%3EYYYY-MM-DD)
-  - `is:pr state:closed no:milestone closed:>YYYY-MM-DD`
+  - `is:pr is:merged no:milestone closed:>YYYY-MM-DD`
     [filter](https://github.com/falcosecurity/falco/pulls?q=is%3Apr+is%3Amerged+no%3Amilestone+closed%3A%3EYYYY-MM-DD)
 - Assign any issue/PR identified in the previous point to the milestone corresponding to the currently undergoing release
-- Check the release note block of every PR matching the `is:pr is:merged closed:>YYYY-MM-DD` [filter](https://github.com/falcosecurity/falco/pulls?q=is%3Apr+is%3Amerged+closed%3A%3EYYYY-MM-DD)
+- Check the release note block of every PR matching the `is:pr is:merged milestone:M.m.p` [filter](https://github.com/falcosecurity/falco/pulls?q=is%3Apr+is%3Amerged+milestone%3AM.m.p)
     - Ensure the release note block follows the [commit convention](https://github.com/falcosecurity/.github/blob/master/CONTRIBUTING.md#commit-convention), otherwise fix its content
     - If the PR has no milestone, assign it to the milestone currently undergoing release
 
@@ -116,7 +116,7 @@ The release PR is meant to be made against the respective `release/M.m.x` branch
     - If any, manually correct it then open an issue to automate version number bumping later
     - Versions table in the `README.md` updates itself automatically
 - Generate the change log using [rn2md](https://github.com/leodido/rn2md):
-    - Execute `rn2md -r falcosecurity/falco -m M.m.p -b release/M.m.x`
+    - Execute `rn2md -r falcosecurity/falco -m M.m.p`
     - In case `rn2md` emits error try to generate an GitHub OAuth access token and provide it with the `-t` flag
 - Add the latest changes on top the previous `CHANGELOG.md`
 - Submit a PR with the above modifications
@@ -129,16 +129,18 @@ The release PR is meant to be made against the respective `release/M.m.x` branch
 Core maintainers and/or the release manager can decide to publish pre-releases at any time before the final release
 is live for development and testing purposes.
 
-The prerelease tag must be formatted as `M.m.p-r` where `r` is the prerelease version information (e.g. `0.35.0-rc1`.)
+The pre-release must be associated with a newly created tag. The tag is intended to be created while drafting the new pre-release through the GitHub form (this is indeed the only way to correctly associate the tag with a target branch; more on this below).
+The pre-release tag must be formatted as `M.m.p-r`, where `r` is the pre-release version information (e.g. `0.35.0-rc1`).
 
-To do so:
+To create both pre-release tag and pre-release, do the following:
 
 - [Draft a new release](https://github.com/falcosecurity/falco/releases/new)
-- Use `M.m.p-r` both as tag version and release title.
+- Use `M.m.p-r` both as tag version and release title
+- Associate `release/M.m.x` as "target branch" for the new tag
 - Check the "Set as a pre-release" checkbox and make sure "Set as the latest release" is unchecked
 - It is recommended to add a brief description so that other contributors will understand the reason why the prerelease is published
 - Publish the prerelease!
-- The release pipeline will start automatically. Packages will be uploaded to the `-dev` bucket and container images will be tagged with the specified tag.
+- The release pipeline will start automatically. Packages will be uploaded to the `-dev` bucket and container images will be tagged with the specified tag
 
 In order to check the status of the release pipeline click on the [GitHub Actions tab](https://github.com/falcosecurity/falco/actions?query=event%3Arelease) in the Falco repository and filter by release.
 
@@ -150,6 +152,7 @@ Assume `M.m.p` is the new version.
 
 - [Draft a new release](https://github.com/falcosecurity/falco/releases/new)
 - Use `M.m.p` both as tag version and release title
+- Associate `release/M.m.x` as "target branch" for the new tag
 - Do NOT fill body, since it will be autogenerated by the [github release workflow](.github/workflows/release.yaml)
 - Publish the release!
 - The release pipeline will start automatically upon publication and all packages and container images will be uploaded to the stable repositories.

cmake/cpack/debian/conffiles

@@ -1,3 +1,3 @@
 /etc/falco/falco.yaml
-/etc/falco/falcoctl.yaml
 /etc/falco/falco_rules.local.yaml
+/etc/falcoctl/falcoctl.yaml

cmake/modules/driver.cmake

@@ -35,9 +35,9 @@ else()
 	# FALCOSECURITY_LIBS_VERSION. In case you want to test against another driver version (or
 	# branch, or commit) just pass the variable - ie., `cmake -DDRIVER_VERSION=dev ..`
 	if(NOT DRIVER_VERSION)
-		set(DRIVER_VERSION "9.0.0+driver")
+		set(DRIVER_VERSION "9e6a8ccd4e4f5796f45ad486decd00b4996129b7")
 		set(DRIVER_CHECKSUM
-			"SHA256=ef563fe19f9cdbdfcf17cee3e83c79e8387b78a87e0593eb3e2787c9b8540113"
+			"SHA256=87902814e29718529094b89ff2a3ddbd4ee7aa77da824d4acbaad0d863e04ce9"
 		)
 	endif()
 

cmake/modules/falcosecurity-libs.cmake

@@ -42,9 +42,9 @@ else()
 	# version (or branch, or commit) just pass the variable - ie., `cmake
 	# -DFALCOSECURITY_LIBS_VERSION=dev ..`
 	if(NOT FALCOSECURITY_LIBS_VERSION)
-		set(FALCOSECURITY_LIBS_VERSION "0.22.2")
+		set(FALCOSECURITY_LIBS_VERSION "9e6a8ccd4e4f5796f45ad486decd00b4996129b7")
 		set(FALCOSECURITY_LIBS_CHECKSUM
-			"SHA256=53cfb7062cac80623dec7496394739aabdfee8a774942f94be0990d81e3b2fbc"
+			"SHA256=87902814e29718529094b89ff2a3ddbd4ee7aa77da824d4acbaad0d863e04ce9"
 		)
 	endif()
 

docker/falco/Dockerfile

@@ -34,12 +34,11 @@ RUN FALCO_VERSION_URLENCODED=$(echo -n ${FALCO_VERSION}|jq -sRr @uri) && \
     mv falco-${FALCO_VERSION}-$(uname -m) falco && \
     rm -rf /falco/usr/src/falco-* && \
     cp -r /falco/* / && \
-    rm -rf /falco
+    rm -rf /falco && \
+    rm -rf /usr/bin/falcoctl /etc/falcoctl/
+
 
 # Change the falco config within the container to enable ISO 8601 output.
 ADD ./config/falco.iso8601_timeformat.yaml /etc/falco/config.d/
 
-# Falcoctl is not included here.
-RUN rm -rf /usr/bin/falcoctl /etc/falcoctl/
-
 CMD ["/usr/bin/falco"]

proposals/20251215-legacy-bpf-grpc-output-gvisor-engine-deprecation.md

@@ -0,0 +1,127 @@
+# Legacy eBPF probe, gVisor libscap engine and gRPC output deprecations
+
+## Summary
+
+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.
+
+## Motivation
+
+### Legacy eBPF probe deprecation
+
+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](https://github.com/torvalds/linux/commit/055b1212d141f1f398fca548f8147787c0b6253f) | >= 4.17                                                                                     | >= 5.8            | _STABLE_ |
+| **s390x**   | >= 3.10                                                                                        | >= [5.5](https://github.com/torvalds/linux/commit/6ae08ae3dea)                              | >= 5.8            | _EXPERIMENTAL_ |
+| **riscv64** | >= [5.0](https://github.com/torvalds/linux/commit/5aeb1b36cedd3a1dfdbfe368629fed52dee34103)  | N/A                                                                                         | N/A               | _EXPERIMENTAL_ |
+| **ppc64le** | >= 3.10                                                                                        | >= [5.1](https://github.com/torvalds/linux/commit/ed1cd6deb013a11959d17a94e35ce159197632da) | >= 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:
+1. it cannot leverage CORE eBPF features - as a result, falcosecurity must maintain a great number of officially
+supported eBPF objects, each one built for a specific officially-supported kernel flavor; this increases the
+maintainability burden and makes the system less flexible to kernel configurations/structures changes
+2. old kernel versions support is difficult to retain - the verifier imposes huge limitations on old kernel versions,
+and any tiny change easily result in the verifier rejecting the code
+3. it is difficult to keep it up to date with other drivers - some desired features cannot be implemented in any way
+using eBPF on old kernel flavors, due to lack of eBPF helpers/program types or verifier limitations (e.g.: there is no
+way of implementing a synchronous data harvesting mechanism like the one provided by BPF iterators). As falcosecurity
+strives for feature parity among drivers, this imposes a big limitation on the other drivers. Please notice that:
+   1. the kernel module is unconstrained on the nature of feature it can support
+   2. the modern eBPF probe can easily rely on CORE features to probe for kernel features and use them if available
+
+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 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`.
+
+### gRPC output deprecation
+
+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`.
+
+## Goals
+
+* Deprecate the legacy eBPF probe, the gVisor libscap engine, and the gRPC output
+* Detail a plan to follow during the deprecation period, before completely remove any of the aforementioned components
+
+## Non-goals
+
+* Implement a gVisor source plugin as gVisor libscap engine alternative
+* Implement the gRPC output as Falco Sidekick output
+* Detail a plan to follow after taking the decision to completely remove any of the aforementioned components
+
+## The plan
+
+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](./20231220-features-adoption-and-deprecation.md#deprecation-policy)).
+
+All components are stable, and given that the current stable Falco version is `0.42.1` (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:
+- on `falcosecurity/libs`, any CI job building and testing the legacy eBPF probe will be removed
+- on `falcosecurity/kernel-testing`, playbooks will not build and test the legacy eBPF probe anymore
+- on `falcosecurity/event-generator`, the internal gRPC alert retriever will be replaced with an HTTP alert retriever,
+leveraging the existing HTTP output.
+
+## The non-plan
+
+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.

scripts/falcoctl/falcoctl.yaml.in

@@ -7,7 +7,7 @@ driver:
     hostroot: "/"
 artifact:
   follow:
-    every: 6h0m0s
+    every: 168h0m0s
     falcoVersions: http://localhost:8765/versions
     refs:
     - falco-rules:5

userspace/engine/falco_engine_version.h

@@ -20,7 +20,7 @@ limitations under the License.
 
 // The version of this Falco engine
 #define FALCO_ENGINE_VERSION_MAJOR 0
-#define FALCO_ENGINE_VERSION_MINOR 57
+#define FALCO_ENGINE_VERSION_MINOR 58
 #define FALCO_ENGINE_VERSION_PATCH 0
 
 #define FALCO_ENGINE_VERSION                                                               \
@@ -36,4 +36,4 @@ limitations under the License.
 // It represents the fields supported by this version of Falco,
 // the event types, and the underlying driverevent schema. It's used to
 // detetect changes in engine version in our CI jobs.
-#define FALCO_ENGINE_CHECKSUM "fc2c6a925b4f7d59efd79f752ff5db2460e778ec00788213c5b7292e0a80586f"
+#define FALCO_ENGINE_CHECKSUM "952fa3356bfd266419810be51ae659eab48093a66da26fff3897022a9de2c08c"

userspace/engine/falco_load_result.cpp

@@ -143,7 +143,12 @@ const std::string& falco::load_result::warning_desc(warning_code wc) {
 	return warning_descs[static_cast<int>(wc)];
 }
 
-static const std::string deprecated_fields[] = {"evt.dir"};
+static const std::string deprecated_fields[] = {"evt.dir",
+                                                "evt.latency",
+                                                "evt.latency.s",
+                                                "evt.latency.ns",
+                                                "evt.latency.human",
+                                                "evt.wait_latency"};
 
 // Compile-time check to ensure deprecated_fields array has the correct size
 static_assert(
@@ -155,10 +160,19 @@ const std::string& falco::load_result::deprecated_field_str(deprecated_field df)
 	return deprecated_fields[static_cast<int>(df)];
 }
 
+// Shared description suffix for latency fields
+static const std::string latency_field_desc_suffix =
+        "field is not available due to the drop of enter events.";
+
 static const std::string deprecated_field_descs[] = {
         "due to the drop of enter events, 'evt.dir = <' always evaluates to true, and 'evt.dir = "
         ">' always evaluates to false. The rule expression can be simplified by removing the "
-        "condition on 'evt.dir'"};
+        "condition on 'evt.dir'",
+        latency_field_desc_suffix,
+        latency_field_desc_suffix,
+        latency_field_desc_suffix,
+        latency_field_desc_suffix,
+        latency_field_desc_suffix};
 
 // Compile-time check to ensure deprecated_field_descs array has the correct size
 static_assert(

userspace/engine/falco_load_result.h

@@ -75,7 +75,15 @@ public:
 	// impact.
 	static const std::string& warning_desc(warning_code ec);
 
-	enum class deprecated_field { DEPRECATED_FIELD_EVT_DIR, DEPRECATED_FIELD_NOT_FOUND };
+	enum class deprecated_field {
+		DEPRECATED_FIELD_EVT_DIR,
+		DEPRECATED_FIELD_EVT_LATENCY,
+		DEPRECATED_FIELD_EVT_LATENCY_S,
+		DEPRECATED_FIELD_EVT_LATENCY_NS,
+		DEPRECATED_FIELD_EVT_LATENCY_HUMAN,
+		DEPRECATED_FIELD_EVT_WAIT_LATENCY,
+		DEPRECATED_FIELD_NOT_FOUND
+	};
 
 	// The deprecated field as a string
 	static const std::string& deprecated_field_str(deprecated_field df);

userspace/engine/rule_loader.h

@@ -215,8 +215,7 @@ struct deprecated_field_warning : warning {
 	        df(df) {}
 
 	std::string as_string() const override {
-		return warning::as_string() + ": field '" + falco::load_result::deprecated_field_str(df) +
-		       "' is deprecated";
+		return warning::as_string() + ": field '" + falco::load_result::deprecated_field_str(df);
 	};
 	std::string description() const override {
 		return warning::description() + ": " + falco::load_result::deprecated_field_desc(df);

userspace/falco/falco_metrics.cpp

@@ -150,13 +150,15 @@ std::string falco_metrics::falco_to_text_prometheus(
 	// # HELP falcosecurity_falco_outputs_queue_num_drops_total https://falco.org/docs/metrics/
 	// # TYPE falcosecurity_falco_outputs_queue_num_drops_total counter
 	// falcosecurity_falco_outputs_queue_num_drops_total 0
-	additional_wrapper_metrics.emplace_back(libs::metrics::libsinsp_metrics::new_metric(
-	        "outputs_queue_num_drops",
-	        METRICS_V2_MISC,
-	        METRIC_VALUE_TYPE_U64,
-	        METRIC_VALUE_UNIT_COUNT,
-	        METRIC_VALUE_METRIC_TYPE_MONOTONIC,
-	        state.outputs->get_outputs_queue_num_drops()));
+	if(state.outputs != nullptr) {
+		additional_wrapper_metrics.emplace_back(libs::metrics::libsinsp_metrics::new_metric(
+		        "outputs_queue_num_drops",
+		        METRICS_V2_MISC,
+		        METRIC_VALUE_TYPE_U64,
+		        METRIC_VALUE_UNIT_COUNT,
+		        METRIC_VALUE_METRIC_TYPE_MONOTONIC,
+		        state.outputs->get_outputs_queue_num_drops()));
+	}
 
 	// # HELP falcosecurity_falco_reload_timestamp_nanoseconds https://falco.org/docs/metrics/
 	// # TYPE falcosecurity_falco_reload_timestamp_nanoseconds gauge