libsinsp, libscap, the kernel module driver, and the eBPF driver sources

Overview

falcosecurity/libs

As per the OSS Libraries Contribution Plan, this repository has been chosen to be the new home for libsinsp, libscap, the kernel module driver and the eBPF driver sources which Sysdig Inc. has contributed to the Falco project.

Those libraries and drivers have been originally developed as part of the draios/sysdig repository.

Issues
  • new(proposals): API versioning for user/kernel boundary

    new(proposals): API versioning for user/kernel boundary

    What type of PR is this?

    Uncomment one (or more) /kind <> lines:

    /kind bug

    /kind cleanup

    /kind design

    /kind documentation

    /kind failing-test

    /kind feature

    Any specific area of the project related to this PR?

    Uncomment one (or more) /area <> lines:

    /area build

    /area driver-kmod

    /area driver-ebpf

    /area libscap

    /area libsinsp

    /area tests

    /area proposals

    What this PR does / why we need it:

    This proposal introduces semver-compatible version checks for the user/kernel boundary, i.e. between the kernel driver/eBPF probe and the userspace components.

    Which issue(s) this PR fixes:

    Fixes #

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    NONE
    
    dco-signoff: yes release-note-none lgtm approved size/L area/proposals 
    opened by gnosek 16
  • wip: add is_exe_writable flag to execve

    wip: add is_exe_writable flag to execve

    What type of PR is this?

    Uncomment one (or more) /kind <> lines:

    /kind feature

    Any specific area of the project related to this PR?

    Uncomment one (or more) /area <> lines:

    /area driver-kmod

    /area driver-ebpf

    /area libscap

    What this PR does / why we need it:

    This PR adds the is_exe_writable flag to execve events, and tracks it as a flag in the process structure. The flag is set if the user running the process has ownership or write access to the executable file. This flag can be meaningful when the user in question is not root (to be more precise, root with CAP_FOWNER). In some scenarios it is interesting to analyze whether or not the regular user that spawned a process wrote its own binary. Sometimes this behavior is not expected and so I feel it is worth having this flag so that it can be used in Falco rules to catch these cases.

    Special notes for your reviewer:

    Alas, the bpf probe part of this PR is not currently working (verifier fails on the compiled probe). It sounds like this can get better after some improvements to the BPF probe in this PR https://github.com/falcosecurity/libs/pull/5 .

    Does this PR introduce a user-facing change?:

    new: A new flag, is_exe_writable, is available for execve events. This tracks whether or not the user invoking the systemcall has ownership or write access to the executable file used.
    
    kind/feature release-note dco-signoff: yes do-not-merge/work-in-progress area/driver-kmod area/driver-ebpf area/libscap size/L ok-to-test lifecycle/rotten 
    opened by luca-sd 10
  • docs: add libsinsp example code and documentation

    docs: add libsinsp example code and documentation

    Signed-off-by: David Windsor [email protected]

    What type of PR is this?

    Uncomment one (or more) /kind <> lines: /kind documentation

    Uncomment one (or more) /area <> lines: /area libsinsp

    What this PR does / why we need it: add libsinsp example code and documentation

    Which issue(s) this PR fixes: https://github.com/falcosecurity/libs/issues/31

    Fixes #

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    new: added libsinsp example code and documentation
    
    release-note dco-signoff: yes size/XXL lgtm approved area/libsinsp ok-to-test 
    opened by dwindsor-scwx 10
  • Get k8s pod metadata and namespace name from container labels

    Get k8s pod metadata and namespace name from container labels

    What type of PR is this?

    /kind feature

    Any specific area of the project related to this PR?

    /area libsinsp

    What this PR does / why we need it: Since we run a large kubernetes deployment, we ran into this issue: https://github.com/falcosecurity/falco/issues/778

    We can get the pod metadata and namespace name directly from the container labels instead of the k8s apiserver which is a lot more efficient

    Which issue(s) this PR fixes: doesn't necessarily https://github.com/falcosecurity/falco/issues/778 but it is a workaround for us fixes https://github.com/falcosecurity/falco/issues/1585

    Special notes for your reviewer: I'm a noob at C++ so there might be better ways to do this

    Does this PR introduce a user-facing change?:

    new(userspace/libsinsp): try to get the k8s pod metadata and namespace name from the container labels if they exist
    
    kind/feature release-note dco-signoff: yes lgtm approved area/libsinsp size/L ok-to-test 
    opened by zemek 10
  • Detect containerd containers when SystemdCgroup is not configured

    Detect containerd containers when SystemdCgroup is not configured

    What type of PR is this?

    /kind bug

    Any specific area of the project related to this PR?

    /area libscap

    /area libsinsp

    What this PR does / why we need it:

    In the linked issue, there was a cgroup layout in /proc/[pid]/cgroup which was not supported in libscap and libsinsp. It took the form /system.slice/containerd.service/kubepods-burstable-podb4f3dfaf_f987_499d_a04c_2c60eb01958c.slice:cri-containerd:f659de946112140fd722cddfd24015a8c9fce51b7ab7f007ac30612b6f9acfc9 and was only observed when SystemdCgroup is not configured in containerd.

    The libscap change makes it so we always read the cgroup to the end of the line when reading from /proc/[pid]/cgroup. With the cgroup layout observed in the issue, the previous behavior would only read up to the first : and drop the rest, including the container ID which libsinsp requires in order to detect the container.

    The libsinsp change adds the cgroup layout observed in the issue to the CRI cgroup layout array. This allows for libsinsp to detect and parse the container ID from the cgroup string.

    Which issue(s) this PR fixes:

    Fixes #63

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    fix(libscap, libsinsp): Detect containerd containers when SystemdCgroup is not configured
    
    kind/bug release-note dco-signoff: yes lgtm approved size/XS area/libscap area/libsinsp ok-to-test 
    opened by bawhetst 9
  • Update/licenses refinement

    Update/licenses refinement

    What type of PR is this?

    Uncomment one (or more) /kind <> lines:

    /kind bug

    /kind cleanup

    /kind design

    /kind documentation

    /kind failing-test

    /kind feature

    Any specific area of the project related to this PR?

    Uncomment one (or more) /area <> lines:

    /area build

    /area driver-kmod

    /area driver-ebpf

    /area libscap

    /area libsinsp

    /area tests

    What this PR does / why we need it:

    Small adjustments to licenses.

    Which issue(s) this PR fixes:

    Fixes #

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    NONE
    
    kind/documentation dco-signoff: yes release-note-none lgtm approved size/M kind/cleanup 
    opened by leogr 9
  • Ssprod 7548 agent libs 1 lua modernize

    Ssprod 7548 agent libs 1 lua modernize

    What type of PR is this?

    Uncomment one (or more) /kind <> lines:

    /kind bug

    /kind cleanup

    /kind design

    /kind documentation

    /kind failing-test

    /kind feature

    Any specific area of the project related to this PR?

    Uncomment one (or more) /area <> lines:

    /area build

    /area driver-kmod

    /area driver-ebpf

    /area libscap

    /area libsinsp

    /area tests

    /area proposals

    What this PR does / why we need it: Changes needed to support aarch64 (64-bit ARM) architecture

    Which issue(s) this PR fixes: Part of the fix for SSPROD-7548

    Fixes #

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    NONE
    
    kind/feature size/XXL release-note-none area/build dco-signoff: no needs-ok-to-test do-not-merge/contains-merge-commits 
    opened by jcpittman144 9
  • Parametrize the metadata download

    Parametrize the metadata download

    This commit adds a new sinsp public API (set_metadata_download_params), allowing the user modify some of the key parameters that determine the behavior of metadata download from orchestrators like Kubernetes or Mesos.

    The commit also changes the default value of some of the metadata download parameters. Specifically, the maximum startup download size goes from 30MB to 100MB, and the chunck wait delay goes from 10ms to 1ms.

    Signed-off-by: Loris Degioanni [email protected]

    What type of PR is this?

    Uncomment one (or more) /kind <> lines:

    /kind bug

    /kind cleanup

    /kind design

    /kind documentation

    /kind failing-test

    /kind feature

    Any specific area of the project related to this PR?

    Uncomment one (or more) /area <> lines:

    /area build

    /area driver-kmod

    /area driver-ebpf

    /area libscap

    /area libsinsp

    /area tests

    What this PR does / why we need it:

    Which issue(s) this PR fixes:

    Fixes #

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    new: sinsp public API method `set_metadata_download_params` allows the user to modify some of the key parameters that determine the behavior of metadata download from orchestrators like Kubernetes or Mesos.
    
    kind/feature release-note dco-signoff: yes lgtm approved area/libsinsp size/L 
    opened by ldegio 7
  • Ssprod 7609

    Ssprod 7609

    What type of PR is this?

    Uncomment one (or more) /kind <> lines:

    /kind bug

    /kind cleanup

    /kind design

    /kind documentation

    /kind failing-test

    /kind feature

    Any specific area of the project related to this PR?

    Uncomment one (or more) /area <> lines:

    /area build

    /area driver-kmod

    /area driver-ebpf

    /area libscap

    /area libsinsp

    /area tests

    /area proposals

    What this PR does / why we need it:

    Which issue(s) this PR fixes:

    Fixes #

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    
    
    size/XXL do-not-merge/release-note-label-needed do-not-merge/work-in-progress dco-signoff: no needs-ok-to-test do-not-merge/contains-merge-commits 
    opened by VadimZy 7
  • new(.gitpod): cloud kernel development environment on gitpod

    new(.gitpod): cloud kernel development environment on gitpod

    Signed-off-by: Lorenzo Fontana [email protected]

    What type of PR is this?

    /kind documentation

    Any specific area of the project related to this PR?

    /area build

    /area driver-kmod

    /area driver-ebpf

    What this PR does / why we need it:

    The Falco libraries are used to interact with the Linux kernel via either the Falco Kernel Module or the eBPF probe.

    Contributors might find hard to maintain and use a development environment suitable for Kernel development when they need to make changes to those components from time to time.

    To make that easy, here we have a complete and ready to use environment running as a Gitpod workspace.

    Which issue(s) this PR fixes:

    Fixes #

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    NONE
    
    kind/documentation dco-signoff: yes size/XXL release-note-none area/build area/driver-kmod area/driver-ebpf 
    opened by fntlnz 7
  • fix(libsinsp,libscap): safer string use, avoid warnings on gcc 8+

    fix(libsinsp,libscap): safer string use, avoid warnings on gcc 8+

    What type of PR is this?

    Uncomment one (or more) /kind <> lines:

    /kind bug

    /kind cleanup

    /kind design

    /kind documentation

    /kind failing-test

    /kind feature

    Any specific area of the project related to this PR?

    Uncomment one (or more) /area <> lines:

    /area build

    /area driver-kmod

    /area driver-ebpf

    /area libscap

    /area libsinsp

    /area tests

    /area proposals

    What this PR does / why we need it:

    Some functions were using the strncpy function to copy a number of characters between strings. This is not in itself bad, but it is error prone, since strncpy does not add a terminating \0 if the string length is equal or exceeds the max specified. So we'd need to manually add a null terminator. Some compilers, such as GCC 8, emit a warning about many uses of strncpy. This can simply be fixed by using snprintf(dest, len, "%s", src) instead which has a saner behavior.

    In addition, upgrade tinydir to the latest version, fixing similar problems.

    Which issue(s) this PR fixes:

    Fixes #

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    NONE
    
    dco-signoff: yes size/XXL release-note-none kind/cleanup area/libscap area/libsinsp needs-ok-to-test 
    opened by lucklypse 2
  • Minor improvements

    Minor improvements

    What type of PR is this?

    /kind cleanup

    Any specific area of the project related to this PR?

    /area libscap

    What this PR does / why we need it:

    It is made up by 2 separate commits:

    • first one will make use of c11 _Static_assert() for g_syscall_info_table and g_event_info. This means that any issue is caught at compile time. Moreover, with static_assert() we also cover the cases where the expected size was greater than actually declared fields (before we would've empty fields, but the array size was fixed during declaration)
    • Avoid defining enum fields value when they start from 0 and grow by 1; this is a stylish commit to increase code readability with the side effect to mandate less chance of errors (eg: forgetting to increase enum MAX value)

    Which issue(s) this PR fixes:

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    NONE
    
    dco-signoff: yes size/XXL release-note-none kind/cleanup area/libscap ok-to-test 
    opened by FedeDP 4
  • Fix containers metadata json

    Fix containers metadata json

    What type of PR is this?

    /kind bug

    Any specific area of the project related to this PR?

    /area libsinsp

    What this PR does / why we need it:

    Properly trim useless container metadata when resulting json is too large to be handled as an event payload (currently limited to 64kiB given our protocol); trim first useless metadata, ie: "port_mappings", "env" and "labels".
    If still out of space, trim "Mounts" too.
    Best-effort to keep "Mounts" that can be used as filters.

    Which issue(s) this PR fixes:

    Fixes #51

    Special notes for your reviewer:

    A flexible array member was introduced in struct ppm_evt_hdr for better readability.

    Does this PR introduce a user-facing change?:

    NONE
    
    kind/bug dco-signoff: yes release-note-none size/M area/libsinsp needs-ok-to-test 
    opened by FedeDP 2
  • fix(libsinsp): fix formatter for bytebuf types

    fix(libsinsp): fix formatter for bytebuf types

    Signed-off-by: lucklypse [email protected]

    What type of PR is this?

    Uncomment one (or more) /kind <> lines:

    /kind bug

    /kind cleanup

    /kind design

    /kind documentation

    /kind failing-test

    /kind feature

    Any specific area of the project related to this PR?

    Uncomment one (or more) /area <> lines:

    /area build

    /area driver-kmod

    /area driver-ebpf

    /area libscap

    /area libsinsp

    /area tests

    /area proposals

    What this PR does / why we need it:

    Fix variable passing when attempting to format rawarg type values. This is in general not a very smart thing to do and is not really used in Falco but could be used in other clients, (if they tried they would incur in a segfault, this pr fixes that).

    Which issue(s) this PR fixes:

    Fixes #

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    fix(libsinsp): segfault in rawarg formatter
    
    kind/bug release-note dco-signoff: yes size/S lgtm approved area/libsinsp ok-to-test 
    opened by lucklypse 4
  • fix(driver): fix bpf probe verifier on linux 5.14 and llvm 12.0.1

    fix(driver): fix bpf probe verifier on linux 5.14 and llvm 12.0.1

    Signed-off-by: Federico Di Pierro <[email protected]>
    Co-authored-by: Jason Dellaluce <[email protected]>
    

    What type of PR is this?

    /kind bug

    Any specific area of the project related to this PR?

    /area driver-ebpf

    What this PR does / why we need it:

    So far, the eBPF probe needs to be compiled with clang 7. Although newer versions of clang can successfully compile the probe, it then gets rejected by the kernel verifier. This has been an open issue for a while.

    This PR applies a small set of fixes that allow our eBPF probe to be accepted by the kernel verifier even when compiled with recent versions of clang.
    So far, we tested this on various versions of the linux kernel and of clang.
    These are the results of our test grid, which we ran on amd64 architecture:

    | Kernel Ver. | 5.14 | 5.11 | 5.8 | 5.4 | 4.19 | 4.17 | 4.15 | |:------------:|:----:|:----:|:---:|:---:|:----:|:----:|:----:| | clang-7 | -- | OK | OK | OK | OK | OK | OK | | clang-8 | -- | OK | OK | OK | OK | OK | OK | | clang-9 | -- | OK | OK | OK | OK | OK | OK | | clang-10 | -- | OK | OK | OK | OK | OK | OK | | clang-11 | -- | OK | OK | OK | OK | OK | OK | | clang-12 | OK | OK | OK | OK | OK | OK | OK | | clang-14 | -- | OK | OK | OK | OK | OK | KO |

    Additional context

    At a high level, the kernel verifier rejects the eBPF for three main reasons:

    1. Unclear exit conditions in bounded loops. In some cases where the exit condition of a unrolled loop is a little ambiguous, the verifier is not able to predict if some memory accesses can go out of bounds. An example is visible here. In this case, a check on the off variable is required because it is used to access memory inside data->buf[off & ...]. We solved the error by checking the value of off at the beginning of the loop.
    2. Unprotected memory accesses. Accessing memory with patterns like &buf[off & SCRATCH_SIZE_HALF], visible here, is often rejected if compiled with newest clang versions. This is due to an optimization applied during the compilation. If a check such as if (off > SCRATCH_SIZE_HALF) /* fail /* appears before a memory access such as &buf[off & SCRATCH_SIZE_HALF], the compiler avoids performing the & SCRATCH_SIZE_HALF operation by assuming that the value of off is already bounded because it is checked inside the if statement. However, the compiled eBPF bytecode gets then rejected by the kernel verifier because it has no way to predict the value of off when accessing the memory buffer. We fixed this by storing the result of off & SCRATCH_SIZE_HALF in an additional variable, so that the compiler is forced to perform the bitwise bounding operation.
    3. Passing long integers to eBPF helpers. Helpers such as bpf_probe_read, accept a size argument that is defined as a signed integer. However, in multiple instances (such as here) we pass unsigned long variables as size arguments. We assume the safety of this operation by checking that the value does not go beyond a certain threshold, or by bouding its value through a bitwise and operation, but this is not sufficient. The kernel verifier recognizes an attempt of converting an u64 to a s32, and predicts the possibility of the value to become negative due to the potential bit overflow. We solved this problem by defining the passed value as u16, which was quite sufficient to cover our use cases (our max value fits in 16 bits comfortably).

    Which issue(s) this PR fixes: Fixes #58

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    NONE
    
    kind/bug dco-signoff: yes release-note-none lgtm approved size/M area/driver-ebpf ok-to-test 
    opened by FedeDP 8
  • update(driver): add support to openat2 syscall

    update(driver): add support to openat2 syscall

    Signed-off-by: Jason Dellaluce <[email protected]>
    Co-authored-by: Federico Di Pierro <[email protected]>
    Co-authored-by: Grzegorz Nosek <[email protected]>
    
    

    What type of PR is this?

    /kind feature

    Any specific area of the project related to this PR?

    /area driver-kmod

    /area driver-ebpf

    /area libscap

    /area libsinsp

    What this PR does / why we need it: This adds support for the openat2 system call, along with its transformation flags.

    Which issue(s) this PR fixes: https://github.com/falcosecurity/falco/issues/676

    Does this PR introduce a user-facing change?:

    update(driver): add support to openat2 syscall
    
    kind/feature release-note dco-signoff: yes area/driver-kmod area/driver-ebpf area/libscap area/libsinsp ok-to-test size/XL 
    opened by jasondellaluce 5
  • Users and groups loading code fixes

    Users and groups loading code fixes

    What type of PR is this?

    Uncomment one (or more) /kind <> lines:

    /kind bug

    Any specific area of the project related to this PR?

    Uncomment one (or more) /area <> lines:

    /area libscap /area libsinsp

    What this PR does / why we need it:

    Fix weird edge cases where users/groups where added while libscap was loading them, potentially causing a segfault. Moreover, a sinsp::get_group() api is added, following sinsp::get_user(), and used where needed.

    Interesting fact: libscap only loads the list of users once, during startup; thus the list of users is static, and not dynamically updated. This means that when filtering on a user {name,homedir,shell,loginname} (and the same goes for a group name), events for new users won't be actually managed.

    Steps to reproduce the abort in #19:

    • build libs in debug mode
    • using sysdig tool linking debug-mode-libs, start with an user filter, eg: sudo ./userspace/sysdig/sysdig "user.name=foo"
    • on another shell, add a new user (name does not matter): sudo useradd bar
    • now let's run eg: sudo -u bar echo test
    • see sysdig aborting with sysdig: libs/userspace/libsinsp/filterchecks.cpp:4619: virtual uint8_t* sinsp_filter_check_user::extract(sinsp_evt*, uint32_t*, bool): Assertionuinfo != __null' failed.`

    In release mode, the crash is not triggered, but the filter is doing nothing for newly created users, eg running: sudo ./userspace/sysdig/sysdig "user.name=foo" and then creating a foo user and let it doing stuff, won't trigger any output.

    Which issue(s) this PR fixes:

    Fixes #19

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    NONE
    
    kind/bug dco-signoff: yes release-note-none area/libscap area/libsinsp size/L ok-to-test 
    opened by FedeDP 6
  • Add notion of generic formatters/formatter factories

    Add notion of generic formatters/formatter factories

    Add the notion of "generic" event formatters and formatter factories that can create a formatter for a given format string:

    • gen_filter.h defines two new classes: gen_event_formatter provides the interface to format events:
      • set_format(): set the output format and format string
      • tostring(): resolve the format with info from a gen_event, populating a resolved string.
      • tostring_withformat(): like tostring() but with a one-off output format.
      • get_field_values(): return all templated field names and values from the configured format string.
      • get_output_format(): get the current output format.
    • gen_event_formatter_factory performs a similar role as the existing sinsp_evt_formatter_cache, in that it maintains a cache of previously used format strings/formatters, to avoid the overhead of creating formatters. It simply returns a formatter, though, rather than duplicating the format methods like sinsp_evt_formatter_cache does.

    This can be used in programs like falco to format general purpose events without having a direct connection to an inspector/filterchecks/etc.

    • The eventformatter changes simply add gen_event_formatter as a parent class and implements the interfaces. To aid in backwards compatibility with other parts of libsinsp, this only adds new methods as needed to conform to the gen_event_formatter interface. In some cases, the new methods just call existing methods that did the same thing.

    What type of PR is this?

    Uncomment one (or more) /kind <> lines:

    /kind bug

    /kind cleanup

    /kind design

    /kind documentation

    /kind failing-test

    /kind feature

    Any specific area of the project related to this PR?

    Uncomment one (or more) /area <> lines:

    /area build

    /area driver-kmod

    /area driver-ebpf

    /area libscap

    /area libsinsp

    /area tests

    /area proposals

    What this PR does / why we need it:

    Which issue(s) this PR fixes:

    Fixes #

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    new(libsinsp): add notion of generic event formatters/formatter factories, similar to how filters have generic filters/factories
    
    kind/feature release-note dco-signoff: yes lgtm approved area/libsinsp size/L 
    opened by mstemm 4
  • Update lua parser to be short-lived for a single filter

    Update lua parser to be short-lived for a single filter

    Clean up the interface for lua_parser/lua_parser_api so it doesn't rely on a single object.

    Context--the lua_parser object simply holds some intermediate state (e.g. nesting level) and builds up a gen_filter as the lua side traverses the ast of a filter expression. The lua_parser_api class just has static methods that are registered into lua.

    lua_parser used to be a single object that was reset for each filter. Now, it's an object that is created as a single filter is parsed and deleted afterward. The callbacks always pass the lua_parser object as a first argument and the state/filter in the object is updated.

    Also, registering the lua callbacks is now done via a static method instead of in the constructor.

    Signed-off-by: Mark Stemm [email protected]

    What type of PR is this?

    Uncomment one (or more) /kind <> lines:

    /kind bug

    /kind cleanup

    /kind design

    /kind documentation

    /kind failing-test

    /kind feature

    Any specific area of the project related to this PR?

    Uncomment one (or more) /area <> lines:

    /area build

    /area driver-kmod

    /area driver-ebpf

    /area libscap

    /area libsinsp

    /area tests

    /area proposals

    What this PR does / why we need it:

    Which issue(s) this PR fixes:

    Fixes #

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    update: update LUA parser to be short-lived for a single filter
    
    release-note dco-signoff: yes lgtm approved size/M kind/cleanup area/libsinsp ok-to-test do-not-merge/hold 
    opened by mstemm 5
  • Add ability to return all fields exported by a factory

    Add ability to return all fields exported by a factory

    Add the ability to return all fields exported by a factory. This is important for programs like falco that need to validate rule filter expressions for various event sources, as well as print out sets of supported fields.

    Previously, falco did direct calls to sinsp::get_filtercheck_fields_info but we're trying to standardize everything to work through factories, to make it easier to support new event sources. This PR supports that work.

    Signed-off-by: Mark Stemm [email protected]

    What type of PR is this?

    Uncomment one (or more) /kind <> lines:

    /kind bug

    /kind cleanup

    /kind design

    /kind documentation

    /kind failing-test

    /kind feature

    Any specific area of the project related to this PR?

    Uncomment one (or more) /area <> lines:

    /area build

    /area driver-kmod

    /area driver-ebpf

    /area libscap

    /area libsinsp

    /area tests

    /area proposals

    What this PR does / why we need it:

    Which issue(s) this PR fixes:

    Fixes #

    Special notes for your reviewer:

    Does this PR introduce a user-facing change?:

    new: add ability to return all fields exported by a filter factory. This will be used by Falco to support multiple event sources.
    
    kind/feature release-note dco-signoff: yes lgtm approved size/M area/libsinsp ok-to-test do-not-merge/hold 
    opened by mstemm 6
Owner
Falco
Falco is Container Native Runtime Security
Falco
Example how to run eBPF probes without a usermode process using fentry

Pinning eBPF Probes Simple example to demonstrate how to pin kernel function and syscall probes. Overview From my reading of the kernel code, KProbe a

pat_h/to/file 3 Jun 7, 2021
ebpfkit-monitor is a tool that detects and protects against eBPF powered rootkits

ebpfkit-monitor ebpfkit-monitor is an utility that you can use to statically analyse eBPF bytecode or monitor suspicious eBPF activity at runtime. It

Guillaume Fournier 21 Sep 16, 2021
eBPF bytecode assembler and compiler

An eBPF bytecode assembler and compiler that * Assembles the bytecode to object code. * Compiles the bytecode to C macro preprocessors. Symbolic

Emil Masoumi 6 Aug 22, 2021
A very basic eBPF Load Balancer in a few lines of C

An eBPF Load Balancer from scratch As seen at eBPF Summit 2021. This is not production ready :-) This uses libbpf as a git submodule. If you clone thi

Liz Rice 103 Sep 8, 2021
Cross-connect Linux interfaces with XDP

Cross-connect Linux interfaces with XDP redirect xdp-xconnect daemon is a long-running process that uses a YAML file as its configuration API. For exa

Michael Kashin 26 Sep 16, 2021
some experiments with ebpf

Learning eBPF and some kernel tracing, probe DNS + TCP connection with portable bpf prog. DevEnv Ubuntu 20.04 Install go Install make, clang, llvm Ins

null 3 Sep 13, 2021
skbtracer on ebpf

skbtracer skbtracer 基于 ebpf 技术的 skb 网络包路径追踪利器, 实现代码基于 BCC (required Linux Kernel 4.15+) 使用样例 skbtracer.py # trace

DavadDi 23 Sep 15, 2021
A Rust crate that simplifies the integration of Rust and eBPF programs written in C.

This crate simplifies the compilation of eBPF programs written in C integrating clang with Rust and the cargo build system with functions that can be

Simone Margaritelli 19 Sep 7, 2021
Linux Application Level Firewall based on eBPF and NFQUEUE.

eBPFSnitch eBPFSnitch is a Linux Application Level Firewall based on eBPF and NFQUEUE. It is inspired by OpenSnitch, and Douane, but utilizing modern

Harpo Roeder 604 Sep 19, 2021
mTCP: A Highly Scalable User-level TCP Stack for Multicore Systems

README mTCP is a highly scalable user-level TCP stack for multicore systems. mTCP source code is distributed under the Modified BSD License. For more

null 1.7k Sep 19, 2021
A simple and easy WiFi-enabled ESP8266-powered WSPR and FT8 beacon which uses NTP + DS3231 RTC for timing.

Easy-Digital-Beacons-v1 A simple and easy WiFi-enabled ESP8266-powered WSPR and FT8 beacon which uses NTP + DS3231 RTC for timing. The whole design is

Dhiru Kholia 11 Sep 7, 2021
ZeroMQ core engine in C++, implements ZMTP/3.1

ZeroMQ Welcome The ZeroMQ lightweight messaging kernel is a library which extends the standard socket interfaces with features traditionally provided

The ZeroMQ project 7.2k Sep 15, 2021
the LIBpcap interface to various kernel packet capture mechanism

LIBPCAP 1.x.y by The Tcpdump Group To report a security issue please send an e-mail to [email protected] To report bugs and other problems, contri

The Tcpdump Group 1.7k Sep 19, 2021
High performance in-kernel WireGuard implementation for Windows

WireGuard for the NT Kernel High performance in-kernel WireGuard implementation for Windows WireGuardNT is an implementation of WireGuard, for the NT

WireGuard 40 Sep 16, 2021
Enable eGFX for Thunderbolt Macs with SIP, ART & FileVault support.

Kryptonite enables external GPUs on Macs using Thunderbolt 1 and 2 without compromising on Mac security features such as System Integrity Protection, FileVault, and Authenticated-Root.

Mayank Kumar 47 Sep 17, 2021
Enabling the Windows Subsystem for Linux to include support for Wayland and X server related scenarios

Welcome to WSLg WSLg is short for Windows Subsystem for Linux GUI and the purpose of the project is to enable support for running Linux GUI applicatio

Microsoft 6.1k Sep 22, 2021
Intel Wi-Fi Drivers for macOS

An Intel Wi-Fi Adapter Kernel Extension for macOS, based on the OpenBSD Project.

OpenIntelWireless 4.9k Sep 22, 2021
Bringing rustls into the Apache server.

mod_tls - memory safety for TLS in Apache This repository contains mod_tls, a module for Apache httpd that uses rustls to provide a memory safe TLS im

Internet Security Research Group 17 Aug 16, 2021
QUIC, a multiplexed stream transport over UDP

QUIC, a multiplexed stream transport over UDP QUIC is an experimental protocol aimed at reducing web latency over that of TCP. On the surface, QUIC is

Devsisters Corp. 1.6k Sep 17, 2021