La page Build Falco from source de Falco est la ressource de référence pour comprendre comment compiler Falco à partir des sources. En outre, le dépôt falcosecurity/libs offre des informations précieuses supplémentaires sur les tests et le débogage des bibliothèques sous-jacentes et des pilotes du noyau de Falco.

Voici un exemple de commande cmake qui activera tout ce dont vous avez besoin pour tous les tests unitaires de ce dépôt :

cmake \
-DUSE_BUNDLED_DEPS=ON \
-DBUILD_DRIVER=ON \
-DBUILD_FALCO_MODERN_BPF=ON \
-DCREATE_TEST_TARGETS=ON \
-DBUILD_FALCO_UNIT_TESTS=ON ..;

Compilez et exécutez la suite de tests unitaires :

nproc=$(grep processor /proc/cpuinfo | tail -n 1 | awk '{print $3}');
make -j$(($nproc-1)) falco_unit_tests;
# Run the tests
sudo ./unit_tests/falco_unit_tests;

Vous pouvez éventuellement compiler le driver de votre choix et tester l'exécution du binaire Falco pour effectuer des tests manuels.

Enfin, le projet Falco a déplacé ses tests de régression Falco vers falcosecurity/testing.

1. Les premières lignes de code à la base de Falco ont été écrites il y a quelque temps, à une époque où Go n'avait pas encore le même niveau de maturité et d'adoption qu'aujourd'hui.
2. Le modèle d'exécution de Falco est séquentiel et mono-thread en raison des exigences de suivi d'état de l'outil, de sorte que la plupart des atouts du runtime Go liés à la concurrence ne seraient pas du tout exploités.
3. Le code de Falco touche à de la programmation de très bas niveau à de nombreux endroits, et nous savons tous qu'interfacer Go avec C est possible, mais apporte énormément de complexité et de compromis.
4. En tant qu'outil de sécurité conçu pour absorber un débit extrêmement élevé d'événements par seconde, Falco doit extraire le maximum de performances sur tous les chemins critiques à l'exécution et nécessite un contrôle approfondi de l'allocation mémoire, ce que le runtime Go ne peut pas offrir (le garbage collection entre également en jeu).
5. Bien que Go ne corresponde pas aux exigences techniques du cœur de Falco, nous avons tout de même pensé qu'il pourrait être un bon candidat pour écrire des extensions de Falco via le système de plugins. C'est la raison principale pour laquelle nous avons accordé une attention particulière et une haute priorité au développement du plugin-sdk-go.
6. Go n'est pas une condition requise pour obtenir des binaires liés statiquement. En fait, nous fournissons des builds Falco entièrement statiques depuis quelques années. Le seul problème avec ceux-ci est que le système de plugins ne peut pas être pris en charge avec le modèle actuel de bibliothèques dynamiques que nous avons aujourd'hui.
7. Le système de plugins a été conçu pour prendre en charge plusieurs langages ; de notre côté, maintenir une base de code compatible C est la meilleure stratégie pour garantir une compatibilité inter-langages maximale.
8. En général, les plugins ont des exigences/dépendances GLIBC car ils disposent de liaisons C de bas niveau nécessaires au chargement dynamique. Une solution potentielle pour l'avenir pourrait être de permettre également aux plugins d'être liés statiquement au moment de la compilation et d'être ainsi publiés intégrés au binaire Falco. Bien qu'aucun travail n'ait encore été entrepris dans cette direction, cela résoudrait la plupart des problèmes que vous avez signalés et fournirait également un binaire totalement statique. Bien sûr, cela ne serait plus compatible avec le chargement dynamique, mais cela pourrait être une solution viable pour notre variante de build statique de Falco.
9. La sécurité mémoire est certainement une préoccupation, et nous faisons de notre mieux pour maintenir un niveau de qualité élevé, même si le C++ est assez sujet aux erreurs. Par exemple, nous essayons d'utiliser des pointeurs intelligents (smart pointers) chaque fois que possible, nous compilons les bibliothèques avec un address sanitizer dans notre CI, nous exécutons Falco avec Valgrind avant chaque version, et nous avons des moyens de le soumettre à des tests de stress pour détecter des régressions de performances ou une utilisation anormale de la mémoire (par exemple https://github.com/falcosecurity/event-generator). En plus de cela, des tiers audient également la base de code de temps en temps. Rien de tout cela ne constitue bien sûr une garantie parfaite en matière de sécurité, mais nous essayons de maximiser nos chances. Go nous faciliterait certainement la vie de ce point de vue ; cependant, les compromis n'ont jamais rendu cela rentable jusqu'à présent en raison des points ci-dessus.
10. La base de code C++ de falcosecurity/libs, qui est au cœur de Falco, est assez vaste et complexe. Porter tout ce code vers un autre langage représenterait un effort majeur nécessitant d'importantes ressources de développement et comportant un risque élevé d'échec et de régression. C'est pourquoi notre approche jusqu'à présent a été de privilégier les refactorisations et le polissage du code, jusqu'à ce que nous atteignions un niveau optimal de stabilité, de qualité et de modularité sur cette partie du code. Cela permettrait aux développements futurs d'être plus fluides et plus réalisables à l'avenir.