bpfcov

2022-01-10T00:00:00+00:00

This project provides 2 main components:</p>

libBPFCov.so</code> - an out-of-tree LLVM pass</strong> to instrument</strong> your eBPF programs</strong> for coverage.</li>

bpfcov</code> - a CLI</strong> to collect source-based coverage</strong> from your eBPF programs.</li>
</ol>
</th> </th> </th></tr></thead>

</a></td> </a></td> </a></td></tr>
</a></td> </a></td> </a></td></tr>
</a></td> </a></td> </a></td></tr>
</tbody></table>
Overview§</a>
</h2>
This section aims to provide a high-level overiew of the steps you need to get started with bpfcov</strong>.</p>

Compile the LLVM pass</a> obtaining libBPFCov.so</code></li>
Instrument your eBPF program by compiling it and by running the LLVM pass (libBPFCov.so</code>) on it</li>
Build the userspace code of your eBPF application</li>
Execute your eBPF application in the kernel through the bpfcov run ...</code> command</li>
Generate the .profraw</code> file from the run through the bpfcov gen ...</code> command

Having a .profraw</code> makes this tool fully interoperable</li>
Having a .profraw</code> allows you to generate a variety of coverage reports in different formats</li>
</ol>
</li>
Use the LLVM toolchain to create coverage reports as documented in the LLVM docs</a></li>
</ol>
In case you are impatient and want to jump straight into getting your hands dirty, then the examples</a> directory contains a few dummy eBPF programs to showcase what bpfcov</strong> does.</p>
It basically automates steps 2 and 3. Its README</a> contains more details.</p>
While the README of the cli directory</a> gives you more details about the steps 4 and 5 (and also 6).</p>
Usage§</a>
</h2>
Here I will highlight the manual</em> steps to use it.</p>
I suggest you to automate most of them like I did in the examples Makefile</a>.</p>
Anyway, assuming you have built</a> the LLVM pass, you can then use your fresh libBPFCov.so</code> to instrument your eBPF programs for coverage (steps 2 and 3 above).</p>
How to do it?</p>
First, you need to compile your eBPF program almost as usual but to LLVM IR...</p>
clang</span> -g -O2</span> \</span></span>
    -target</span> bpf</span> -D__TARGET_ARCH_x86 -I$(</span>YOUR_INCLUDES</span>)</span> \</span></span>
    -fprofile-instr-generate -fcoverage-mapping</span> \</span></span>
    -emit-llvm -S</span> \</span></span>
    -c</span> program.bpf.c</span> \</span></span>
    -o</span> program.bpf.ll</span></span></code></pre>
Notice it doesn't matter if you use the textual (*.ll</code>) or the binary form (*.bc</code>).
Obviously, the former is more readable.</p>
The same logic applies to opt</code>: by default it generates *.bc</code>.
Using the -S</code> flag you can obtain the output in textual form (*.ll</code>).</p>
Anyhow, it's time to run the LLVM pass on the LLVM IR we obtained.</p>
Let's do it:</p>
opt</span> -load-pass-plugin</span> $(</span>BUILD_DIR</span>)</span>/lib/libBPFCov.so</span> -passes=</span>"bpf-cov"</span> \</span></span>
    -S</span> program.bpf.ll</span> \</span></span>
    -o</span> program.bpf.cov.ll</span></span></code></pre>
We should have obtained a new LLVM IR that's now valid and loadable from the BPF VM in the Linux kernel. Almost there, YaY!</p>
From it, we can obtain a valid BPF ELF now:</p>
llc</span> -march=bpf -filetype=obj -o</span> cov/program.bpf.o program.bpf.cov.ll</span></span></code></pre>
While we are at it, it is also worth running the LLVM pass again (with a flag) to obtain another BPF ELF containing all the profiling</strong> and coverage mapping</strong> info.
It will come in handy later with llvm-cov</code>.</p>
opt</span> -load</span> $(</span>BUILD_DIR</span>)</span>/lib/libBPFCov.so</span> -strip-initializers-only -bpf-cov</span> \</span></span>
    program.bpf.ll</span> |</span> \</span></span>
    llc</span> -march=bpf -filetype=obj -o</span> cov/program.bpf.obj</span></span></code></pre>
At this point, we can compile our userspace application loading the eBPF instrumented program (cov/program.bpf.o</code>).</p>
Doing this when using libbpf</code> and skeletons is very easy. Nothing different from the common steps: bpftool</code>, cc</code>, etc.</p>
In the examples</a> directory, you can find further explainations.</p>
So assuming we got our instrumented binary ready (cov/program</code>), we can run it via the bpfcov</code> CLI.</p>
sudo</span> ./bpfcov run cov/program</span></span>
# Wait for it to exit, or stop it with CTRL+C</span></span>
sudo</span> ./bpfcov gen</span> --unpin</span> cov/program</span></span></code></pre>
Again, in case you wanna know more about these 2 steps, refer this time to the CLI README</a>.</p>
Now we have a magic cov/program.profraw</code> file...</p>
And we can use the LLVM toolchain to generate very fine-grained coverage reports like those in the screenshots!</p>
Refer to the LLVM docs</a> to learn how to do it.</p>
But no worries, it's just about invoking llvm-profdata</code> and llvm-cov</code>:</p>
lvm-profdata</span> merge</span> -sparse</span> cov/program.profraw</span> -o</span> cov/program.profdata</span></span>
llvm-cov</span> show</span> \</span></span>
    --format=html</span> \</span></span>
    --show-line-counts-or-regions --show-region-summary --show-branch-summary</span> \</span></span>
    --instr-profile=cov/profdata.profdata</span> \</span></span>
    -object</span> cov/program.bpf.obj</span> \</span></span>
    --output-dir=cov/html_report</span></span></code></pre>
Anyayws, bpfcov</strong> also provides you an opinionated shortcut command to generate HTML, JSON, and LCOV coverage reports:</p>
./bpfcov</span> out</span> --format=html</span> cov/program.profraw</span></span></code></pre>Development Environment§</a>
</h2>
In order to build</strong> the BPFCov library (libBPFCov.so</code>) you will need:</p>

LLVM 12+</li>
CMake 3.13.4+</li>
C++ compiler that supports C++14</li>
</ul>
In order to use</strong> it, you will need:</p>

clang 12 (to generate the input LLVM files)</li>
its opt</a> binary to run the LLVM pass</li>
</ul>
This project has been tested on 5.15 Linux kernels.</p>
Building§</a>
</h2>
Build as follows:</p>
mkdir</span> -p</span> build</span> &&</span> cd</span> build</span></span>
cmake</span> -DLT_LLVM_INSTALL_DIR=/path/to/llvm/installation</span> ..</span></span>
make</span></span></code></pre>
Notice that the LT_LLVM_INSTALL_DIR</code> variable should be set to the root of either the installation (usually /usr</code>) or the build directory of LLVM.</p>
It is used to locate the corresponding LLVMConfig.cmake</code> script that is used to set the include and the
library paths.</p>
Testing§</a>
</h2>
TBD</strong></p>
To run the tests you will need to install llvm-lit</strong>.</p>
Usually, you can install it with pip</strong>:</p>
pip</span> install lit</span></span></code></pre>
Running the tests is as simple as:</p>
lit</span> build/test</span></span></code></pre>


falco
2016-01-19T00:00:00+00:00
</a></p>
Falco</a> is a cloud native runtime security tool for Linux operating systems. It is designed to detect and alert on abnormal behavior and potential security threats in real-time.</p>
At its core, Falco is a kernel monitoring and detection agent that observes events, such as syscalls, based on custom rules. Falco can enhance these events by integrating metadata from the container runtime and Kubernetes. The collected events can be analyzed off-host in SIEM or data lake systems.</p>
Falco, originally created by Sysdig</a>, is a graduated project</strong> under the Cloud Native Computing Foundation</a> (CNCF) used in production by various organisations</a>.</p>
For detailed technical information and insights into the cyber threats that Falco can detect, visit the official Falco</a> website.</p>
For comprehensive information on the latest updates and changes to the project, please refer to the Change Log</a>.</p>
The Falco Project§</a>
</h2>
The Falco Project codebase is maintained under the falcosecurity GitHub organization</a>. The primary repository, falcosecurity/falco</a>, holds the source code for the Falco binary, while other sub-projects are hosted in dedicated repositories. This approach of isolating components into specialized repositories enhances modularity and focused development. Notable core repositories</a> include:</p>

falcosecurity/libs</a>: This repository hosts Falco's core libraries, which constitute the majority of the binary’s source code and provide essential features, such as kernel drivers.</li>
falcosecurity/rules</a>: It contains the official ruleset for Falco, offering pre-defined detection rules for various security threats and abnormal behaviors.</li>
falcosecurity/plugins</a>: This repository supports integration with external services through plugins that extend Falco's capabilities beyond syscalls and container events, with plans for evolving specialized functionalities in future releases.</li>
falcosecurity/falcoctl</a>: A command-line utility designed for managing and interacting with Falco.</li>
falcosecurity/charts</a>: This repository provides Helm charts for deploying Falco and its ecosystem, simplifying the installation and management process.</li>
</ul>
For further insights into our repositories and additional details about our governance model, please visit the official hub of The Falco Project: falcosecurity/evolution</a>.</p>
Getting Started with Falco§</a>
</h2>
If you're new to Falco, begin your journey with our Getting Started</a> guide. For production deployments, please refer to our comprehensive Setup</a> documentation.</p>
As final recommendations before deploying Falco, verify environment compatibility, define your detection goals, optimize performance, choose the appropriate build, and plan for SIEM or data lake integration to ensure effective incident response.</p>
Demo Environment§</a>
</h3>
A demo environment is provided via a docker-compose file that can be started on a docker host which includes falco, falcosidekick, falcosidekick-ui and its required redis database. For more information see the docker-compose section</a></p>
Join the Community§</a>
</h2>
To get involved with the Falco Project please visit the Community</a> repository to find more information and ways to get involved.</p>
If you have any questions about Falco or contributing, do not hesitate to file an issue or contact the Falco maintainers and community members for assistance.</p>
How to reach out?</p>

Join the #falco</a> channel on the Kubernetes Slack</a>.</li>
Join the Falco mailing list</a>.</li>
File an issue</a> or make feature requests.</li>
</ul>
Commitment to Falco's Own Security§</a>
</h2>
Full reports of various security audits can be found here</a>.</p>
In addition, you can refer to the falco</a> and libs</a> security sections for detailed updates on security advisories and policies.</p>
To report security vulnerabilities, please follow the community process outlined in the documentation found here</a>.</p>
Building§</a>
</h2>
For comprehensive, step-by-step instructions on building Falco from source, please refer to the official documentation</a>.</p>
Testing§</a>
</h2>

	Expand Testing Instructions</summary>
Falco's Build Falco from source</a> is the go-to resource to understand how to build Falco from source. In addition, the falcosecurity/libs</a> repository offers additional valuable information about tests and debugging of Falco's underlying libraries and kernel drivers.</p>
Here's an example of a cmake</code> command that will enable everything you need for all unit tests of this repository:</p>
cmake</span> \</span></span>
-DUSE_BUNDLED_DEPS=ON</span> \</span></span>
-DBUILD_DRIVER=ON</span> \</span></span>
-DBUILD_FALCO_MODERN_BPF=ON</span> \</span></span>
-DCREATE_TEST_TARGETS=ON</span> \</span></span>
-DBUILD_FALCO_UNIT_TESTS=ON</span> ..</span>;</span></span></code></pre>
Build and run the unit test suite:</p>
nproc</span>=$(</span>grep</span> processor /proc/cpuinfo</span> |</span> tail</span> -n</span> 1</span> |</span> awk</span> '{print $3}'</span>);</span></span>
make</span> -j$((</span>$nproc</span>-1))</span> falco_unit_tests</span>;</span></span>
# Run the tests</span></span>
sudo</span> ./unit_tests/falco_unit_tests</span>;</span></span></code></pre>
Optionally, build the driver of your choice and test run the Falco binary to perform manual tests.</p>
Lastly, The Falco Project has moved its Falco regression tests to falcosecurity/testing</a>.</p>
</details>
</br>
How to Contribute§</a>
</h2>
Please refer to the Contributing</a> guide and the Code of Conduct</a> for more information on how to contribute.</p>
FAQs§</a>
</h2>
Why is Falco in C++ rather than Go or {language}?§</a>
</h3>

	Expand Information</summary>

The first lines of code at the base of Falco were written some time ago, where Go didn't yet have the same level of maturity and adoption as today.</li>
The Falco execution model is sequential and mono-thread due to the statefulness requirements of the tool, and so most of the concurrency-related selling points of the Go runtime would not be leveraged at all.</li>
The Falco code deals with very low-level programming in many places, and we all know that interfacing Go with C is possible but brings tons of complexity and tradeoffs to the table.</li>
As a security tool meant to consume a crazy high throughput of events per second, Falco needs to squeeze performance in all hot paths at runtime and requires deep control on memory allocation, which the Go runtime can't provide (there's also garbage collection involved).</li>
Although Go didn't suit the engineering requirements of the core of Falco, we still thought that it could be a good candidate for writing Falco extensions through the plugin system. This is the main reason we gave special attention and high priority to the development of the plugin-sdk-go.</li>
Go is not a requirement for having statically-linked binaries. In fact, we provide fully-static Falco builds since few years. The only issue with those is that the plugin system can't be supported with the current dynamic library model we currently have.</li>
The plugin system has been envisioned to support multiple languages, so on our end maintaining a C-compatible codebase is the best strategy to ensure maximum cross-language compatibility.</li>
In general, plugins have GLIBC requirements/dependencies because they have low-level C bindings required for dynamic loading. A potential solution for the future could be to also support plugin to be statically-linked at compilation time and so released as bundled in the Falco binary. Although no work started yet in this direction, this would solve most issues you reported and would provide a totally-static binary too. Of course, this would not be compatible with dynamic loading anymore, but it may be a viable solution for our static-build flavor of Falco.</li>
Memory safety is definitely a concern and we try our best to keep an high level of quality even though C++ is quite error prone. For instance, we try to use smart pointers whenever possible, we build the libraries with an address sanitizer in our CI, we run Falco through Valgrind before each release, and have ways to stress-test it to detect performance regressions or weird memory usage (e.g. https://github.com/falcosecurity/event-generator). On top of that, we also have third parties auditing the codebase by time to time. None of this make a perfect safety standpoint of course, but we try to maximize our odds. Go would definitely make our life easier from this perspective, however the tradeoffs never made it worth it so far due to the points above.</li>
The C++ codebase of falcosecurity/libs, which is at the core of Falco, is quite large and complex. Porting all that code to another language would be a major effort requiring lots of development resource and with an high chance of failure and regression. As such, our approach so far has been to choose refactors and code polishing instead, up until we'll reach an optimal level of stability, quality, and modularity, on that portion of code. This would allow further developments to be smoother and more feasibile in the future.</li>
</ol>
</details>
</br>
What's next for Falco?§</a>
</h3>
Stay updated with Falco's evolving capabilities by exploring the Falco Roadmap</a>, which provides insights into the features currently under development and planned for future releases.</p>
License§</a>
</h2>
Falco is licensed to you under the Apache 2.0</a> open source license.</p>
Resources§</a>
</h2>

Governance</a></li>
Code Of Conduct</a></li>
Maintainers Guidelines</a></li>
Maintainers List</a></li>
Repositories Guidelines</a></li>
Repositories List</a></li>
Adopters List</a></li>
Release Process</a></li>
Setup documentation</a></li>
Troubleshooting</a></li>
</ul>

falco

Demo Environment §</a> </h3>
A demo environment is provided via a docker-compose file that can be started on a docker host which includes falco, falcosidekick, falcosidekick-ui and its required redis database. For more information see the docker-compose section</a></p>

Building §</a> </h2>
For comprehensive, step-by-step instructions on building Falco from source, please refer to the official documentation</a>.</p>

How to Contribute §</a> </h2>
Please refer to the Contributing</a> guide and the Code of Conduct</a> for more information on how to contribute.</p>

What's next for Falco?§</a> </h3>
Stay updated with Falco's evolving capabilities by exploring the Falco Roadmap</a>, which provides insights into the features currently under development and planned for future releases.</p>

License §</a> </h2>
Falco is licensed to you under the Apache 2.0</a> open source license.</p>

Resources §</a> </h2>

Governance</a></li>
Code Of Conduct</a></li>
Maintainers Guidelines</a></li>
Maintainers List</a></li>
Repositories Guidelines</a></li>
Repositories List</a></li>
Adopters List</a></li>
Release Process</a></li>
Setup documentation</a></li>
Troubleshooting</a></li> </ul>

leodido.dev - C++

bpfcov

</th>	</th>	</th></tr></thead>
</a></td>	</a></td>	</a></td></tr>
</a></td>	</a></td>	</a></td></tr>
</a></td>	</a></td>	</a></td></tr> </tbody></table> Overview §</a> </h2> This section aims to provide a high-level overiew of the steps you need to get started with bpfcov</strong>.</p> Compile the LLVM pass</a> obtaining `libBPFCov.so</code></li>` `Instrument your eBPF program by compiling it and by running the LLVM pass (libBPFCov.so</code>) on it</li>` `Build the userspace code of your eBPF application</li>` `Execute your eBPF application in the kernel through the bpfcov run ...</code> command</li>` `Generate the .profraw</code> file from the run through the bpfcov gen ...</code> command`Having a .profraw</code> makes this tool fully interoperable</li> Having a .profraw</code> allows you to generate a variety of coverage reports in different formats</li> </ol> </li> Use the LLVM toolchain to create coverage reports as documented in the LLVM docs</a></li> </ol> In case you are impatient and want to jump straight into getting your hands dirty, then the examples</a> directory contains a few dummy eBPF programs to showcase what bpfcov</strong> does.</p> It basically automates steps 2 and 3. Its README</a> contains more details.</p> While the README of the cli directory</a> gives you more details about the steps 4 and 5 (and also 6).</p> Usage§</a> </h2> Here I will highlight the manual</em> steps to use it.</p> I suggest you to automate most of them like I did in the examples Makefile</a>.</p> Anyway, assuming you have built</a> the LLVM pass, you can then use your fresh libBPFCov.so</code> to instrument your eBPF programs for coverage (steps 2 and 3 above).</p> How to do it?</p> First, you need to compile your eBPF program almost as usual but to LLVM IR...</p> clang</span> -g -O2</span> \</span></span> -target</span> bpf</span> -D__TARGET_ARCH_x86 -I$(</span>YOUR_INCLUDES</span>)</span> \</span></span> -fprofile-instr-generate -fcoverage-mapping</span> \</span></span> -emit-llvm -S</span> \</span></span> -c</span> program.bpf.c</span> \</span></span> -o</span> program.bpf.ll</span></span></code></pre> Notice it doesn't matter if you use the textual (.ll</code>) or the binary form (.bc</code>). Obviously, the former is more readable.</p> The same logic applies to opt</code>: by default it generates .bc</code>. Using the -S</code> flag you can obtain the output in textual form (.ll</code>).</p> Anyhow, it's time to run the LLVM pass on the LLVM IR we obtained.</p> Let's do it:</p> opt</span> -load-pass-plugin</span> $(</span>BUILD_DIR</span>)</span>/lib/libBPFCov.so</span> -passes=</span>"bpf-cov"</span> \</span></span> -S</span> program.bpf.ll</span> \</span></span> -o</span> program.bpf.cov.ll</span></span></code></pre> We should have obtained a new LLVM IR that's now valid and loadable from the BPF VM in the Linux kernel. Almost there, YaY!</p> From it, we can obtain a valid BPF ELF now:</p> llc</span> -march=bpf -filetype=obj -o</span> cov/program.bpf.o program.bpf.cov.ll</span></span></code></pre> While we are at it, it is also worth running the LLVM pass again (with a flag) to obtain another BPF ELF containing all the profiling</strong> and coverage mapping</strong> info. It will come in handy later with llvm-cov</code>.</p> opt</span> -load</span> $(</span>BUILD_DIR</span>)</span>/lib/libBPFCov.so</span> -strip-initializers-only -bpf-cov</span> \</span></span> program.bpf.ll</span> \|</span> \</span></span> llc</span> -march=bpf -filetype=obj -o</span> cov/program.bpf.obj</span></span></code></pre> At this point, we can compile our userspace application loading the eBPF instrumented program (cov/program.bpf.o</code>).</p> Doing this when using libbpf</code> and skeletons is very easy. Nothing different from the common steps: bpftool</code>, cc</code>, etc.</p> In the examples</a> directory, you can find further explainations.</p> So assuming we got our instrumented binary ready (cov/program</code>), we can run it via the bpfcov</code> CLI.</p> sudo</span> ./bpfcov run cov/program</span></span> # Wait for it to exit, or stop it with CTRL+C</span></span> sudo</span> ./bpfcov gen</span> --unpin</span> cov/program</span></span></code></pre> Again, in case you wanna know more about these 2 steps, refer this time to the CLI README</a>.</p> Now we have a magic cov/program.profraw</code> file...</p> And we can use the LLVM toolchain to generate very fine-grained coverage reports like those in the screenshots!</p> Refer to the LLVM docs</a> to learn how to do it.</p> But no worries, it's just about invoking llvm-profdata</code> and llvm-cov</code>:</p> lvm-profdata</span> merge</span> -sparse</span> cov/program.profraw</span> -o</span> cov/program.profdata</span></span> llvm-cov</span> show</span> \</span></span> --format=html</span> \</span></span> --show-line-counts-or-regions --show-region-summary --show-branch-summary</span> \</span></span> --instr-profile=cov/profdata.profdata</span> \</span></span> -object</span> cov/program.bpf.obj</span> \</span></span> --output-dir=cov/html_report</span></span></code></pre> Anyayws, bpfcov</strong> also provides you an opinionated shortcut command to generate HTML, JSON, and LCOV coverage reports:</p> ./bpfcov</span> out</span> --format=html</span> cov/program.profraw</span></span></code></pre>Development Environment§</a> </h2> In order to build</strong> the BPFCov library (libBPFCov.so</code>) you will need:</p> LLVM 12+</li> CMake 3.13.4+</li> C++ compiler that supports C++14</li> </ul> In order to use</strong> it, you will need:</p> clang 12 (to generate the input LLVM files)</li> its opt</a> binary to run the LLVM pass</li> </ul> This project has been tested on 5.15 Linux kernels.</p> Building§</a> </h2> Build as follows:</p> mkdir</span> -p</span> build</span> &&</span> cd</span> build</span></span> cmake</span> -DLT_LLVM_INSTALL_DIR=/path/to/llvm/installation</span> ..</span></span> make</span></span></code></pre> Notice that the LT_LLVM_INSTALL_DIR</code> variable should be set to the root of either the installation (usually /usr</code>) or the build directory of LLVM.</p> It is used to locate the corresponding LLVMConfig.cmake</code> script that is used to set the include and the library paths.</p> Testing§</a> </h2> TBD</strong></p> To run the tests you will need to install llvm-lit</strong>.</p> Usually, you can install it with pip</strong>:</p> pip</span> install lit</span></span></code></pre> Running the tests is as simple as:</p> lit</span> build/test</span></span></code></pre> falco 2016-01-19T00:00:00+00:00 </a></p> Falco</a> is a cloud native runtime security tool for Linux operating systems. It is designed to detect and alert on abnormal behavior and potential security threats in real-time.</p> At its core, Falco is a kernel monitoring and detection agent that observes events, such as syscalls, based on custom rules. Falco can enhance these events by integrating metadata from the container runtime and Kubernetes. The collected events can be analyzed off-host in SIEM or data lake systems.</p> Falco, originally created by Sysdig</a>, is a graduated project</strong> under the Cloud Native Computing Foundation</a> (CNCF) used in production by various organisations</a>.</p> For detailed technical information and insights into the cyber threats that Falco can detect, visit the official Falco</a> website.</p> For comprehensive information on the latest updates and changes to the project, please refer to the Change Log</a>.</p> The Falco Project§</a> </h2> The Falco Project codebase is maintained under the falcosecurity GitHub organization</a>. The primary repository, falcosecurity/falco</a>, holds the source code for the Falco binary, while other sub-projects are hosted in dedicated repositories. This approach of isolating components into specialized repositories enhances modularity and focused development. Notable core repositories</a> include:</p> falcosecurity/libs</a>: This repository hosts Falco's core libraries, which constitute the majority of the binary’s source code and provide essential features, such as kernel drivers.</li> falcosecurity/rules</a>: It contains the official ruleset for Falco, offering pre-defined detection rules for various security threats and abnormal behaviors.</li> falcosecurity/plugins</a>: This repository supports integration with external services through plugins that extend Falco's capabilities beyond syscalls and container events, with plans for evolving specialized functionalities in future releases.</li> falcosecurity/falcoctl</a>: A command-line utility designed for managing and interacting with Falco.</li> falcosecurity/charts</a>: This repository provides Helm charts for deploying Falco and its ecosystem, simplifying the installation and management process.</li> </ul> For further insights into our repositories and additional details about our governance model, please visit the official hub of The Falco Project: falcosecurity/evolution</a>.</p> Getting Started with Falco§</a> </h2> If you're new to Falco, begin your journey with our Getting Started</a> guide. For production deployments, please refer to our comprehensive Setup</a> documentation.</p> As final recommendations before deploying Falco, verify environment compatibility, define your detection goals, optimize performance, choose the appropriate build, and plan for SIEM or data lake integration to ensure effective incident response.</p> Demo Environment§</a> </h3> A demo environment is provided via a docker-compose file that can be started on a docker host which includes falco, falcosidekick, falcosidekick-ui and its required redis database. For more information see the docker-compose section</a></p> Join the Community§</a> </h2> To get involved with the Falco Project please visit the Community</a> repository to find more information and ways to get involved.</p> If you have any questions about Falco or contributing, do not hesitate to file an issue or contact the Falco maintainers and community members for assistance.</p> How to reach out?</p> Join the #falco</a> channel on the Kubernetes Slack</a>.</li> Join the Falco mailing list</a>.</li> File an issue</a> or make feature requests.</li> </ul> Commitment to Falco's Own Security§</a> </h2> Full reports of various security audits can be found here</a>.</p> In addition, you can refer to the falco</a> and libs</a> security sections for detailed updates on security advisories and policies.</p> To report security vulnerabilities, please follow the community process outlined in the documentation found here</a>.</p> Building§</a> </h2> For comprehensive, step-by-step instructions on building Falco from source, please refer to the official documentation</a>.</p> Testing§</a> </h2> Expand Testing Instructions</summary> Falco's Build Falco from source</a> is the go-to resource to understand how to build Falco from source. In addition, the falcosecurity/libs</a> repository offers additional valuable information about tests and debugging of Falco's underlying libraries and kernel drivers.</p> Here's an example of a cmake</code> command that will enable everything you need for all unit tests of this repository:</p> cmake</span> \</span></span> -DUSE_BUNDLED_DEPS=ON</span> \</span></span> -DBUILD_DRIVER=ON</span> \</span></span> -DBUILD_FALCO_MODERN_BPF=ON</span> \</span></span> -DCREATE_TEST_TARGETS=ON</span> \</span></span> -DBUILD_FALCO_UNIT_TESTS=ON</span> ..</span>;</span></span></code></pre> Build and run the unit test suite:</p> nproc</span>=$(</span>grep</span> processor /proc/cpuinfo</span> \|</span> tail</span> -n</span> 1</span> \|</span> awk</span> '{print $3}'</span>);</span></span> make</span> -j$((</span>$nproc</span>-1))</span> falco_unit_tests</span>;</span></span> # Run the tests</span></span> sudo</span> ./unit_tests/falco_unit_tests</span>;</span></span></code></pre> Optionally, build the driver of your choice and test run the Falco binary to perform manual tests.</p> Lastly, The Falco Project has moved its Falco regression tests to falcosecurity/testing</a>.</p> </details> </br> How to Contribute§</a> </h2> Please refer to the Contributing</a> guide and the Code of Conduct</a> for more information on how to contribute.</p> FAQs§</a> </h2> Why is Falco in C++ rather than Go or {language}?§</a> </h3> Expand Information</summary> The first lines of code at the base of Falco were written some time ago, where Go didn't yet have the same level of maturity and adoption as today.</li> The Falco execution model is sequential and mono-thread due to the statefulness requirements of the tool, and so most of the concurrency-related selling points of the Go runtime would not be leveraged at all.</li> The Falco code deals with very low-level programming in many places, and we all know that interfacing Go with C is possible but brings tons of complexity and tradeoffs to the table.</li> As a security tool meant to consume a crazy high throughput of events per second, Falco needs to squeeze performance in all hot paths at runtime and requires deep control on memory allocation, which the Go runtime can't provide (there's also garbage collection involved).</li> Although Go didn't suit the engineering requirements of the core of Falco, we still thought that it could be a good candidate for writing Falco extensions through the plugin system. This is the main reason we gave special attention and high priority to the development of the plugin-sdk-go.</li> Go is not a requirement for having statically-linked binaries. In fact, we provide fully-static Falco builds since few years. The only issue with those is that the plugin system can't be supported with the current dynamic library model we currently have.</li> The plugin system has been envisioned to support multiple languages, so on our end maintaining a C-compatible codebase is the best strategy to ensure maximum cross-language compatibility.</li> In general, plugins have GLIBC requirements/dependencies because they have low-level C bindings required for dynamic loading. A potential solution for the future could be to also support plugin to be statically-linked at compilation time and so released as bundled in the Falco binary. Although no work started yet in this direction, this would solve most issues you reported and would provide a totally-static binary too. Of course, this would not be compatible with dynamic loading anymore, but it may be a viable solution for our static-build flavor of Falco.</li> Memory safety is definitely a concern and we try our best to keep an high level of quality even though C++ is quite error prone. For instance, we try to use smart pointers whenever possible, we build the libraries with an address sanitizer in our CI, we run Falco through Valgrind before each release, and have ways to stress-test it to detect performance regressions or weird memory usage (e.g. https://github.com/falcosecurity/event-generator). On top of that, we also have third parties auditing the codebase by time to time. None of this make a perfect safety standpoint of course, but we try to maximize our odds. Go would definitely make our life easier from this perspective, however the tradeoffs never made it worth it so far due to the points above.</li> The C++ codebase of falcosecurity/libs, which is at the core of Falco, is quite large and complex. Porting all that code to another language would be a major effort requiring lots of development resource and with an high chance of failure and regression. As such, our approach so far has been to choose refactors and code polishing instead, up until we'll reach an optimal level of stability, quality, and modularity, on that portion of code. This would allow further developments to be smoother and more feasibile in the future.</li> </ol> </details> </br> What's next for Falco?§</a> </h3> Stay updated with Falco's evolving capabilities by exploring the Falco Roadmap</a>, which provides insights into the features currently under development and planned for future releases.</p> License§</a> </h2> Falco is licensed to you under the Apache 2.0</a> open source license.</p> Resources§</a> </h2> Governance</a></li> Code Of Conduct</a></li> Maintainers Guidelines</a></li> Maintainers List</a></li> Repositories Guidelines</a></li> Repositories List</a></li> Adopters List</a></li> Release Process</a></li> Setup documentation</a></li> Troubleshooting</a></li> </ul>