[BUG] scap bpf engine requires API VERSION major bumps when it shouldn't

Andreagit97 commented 11 months ago

Describe the bug

When the scap bpf engine loads the .o file it scans all elf sections. Right now when the engine finds a new filler section it expects to have the corresponding enum in userspace tables

https://github.com/falcosecurity/libs/blob/dc4ab168074a30a15bbd7308aa7ce5e45c935f25/userspace/libscap/engine/bpf/scap_bpf.c#L596

but this is not always true. Consider this example:

Let's imagine SCAP_MINIMUM_DRIVER_SCHEMA_VERSION is like today:

#define SCAP_MINIMUM_DRIVER_SCHEMA_VERSION PPM_API_VERSION(2, 0, 0)

and we have a driver with SCHEMA VERSION 2.0.0. Now we add a new filler like in this PR https://github.com/falcosecurity/libs/pull/1256 sys_listen_e and we bump the driver SCHEMA VERSION to 2.1.0. When libscap tries to load the new .o with SCHEMA_VERSION 2.1.0 it will fail because it will find a sys_listen_e section not known and will print invalid filler name. For this reason, when we add a new filler we need to bump also a major for the API VERSION until we fix this issue

int prog_id = lookup_filler_id(event);
if(prog_id == -1)
{
    return scap_errprintf(handle->m_lasterr, 0, "invalid filler name: %s", event);
}

this issue happens when we use an old libscap version and a driver with at least one new filler, not a very common case but BTW it is a bug.

How to reproduce it

Build libscap with the commit before this PR and build the bpf probe over this PR, you will see the invalid filler name error when you load the bpf probe

poiana commented 4 months ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

Andreagit97 commented 4 months ago

/remove-lifecycle stale

poiana commented 1 month ago