La guida Build Falco from source di Falco è la risorsa di riferimento per capire come compilare Falco dal sorgente. Inoltre, il repository falcosecurity/libs offre ulteriori informazioni preziose sui test e il debug delle librerie sottostanti e dei driver del kernel di Falco.

Ecco un esempio di comando cmake che abilita tutto il necessario per tutti gli unit test di questo repository:

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

Compila ed esegui la suite di unit test:

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;

Facoltativamente, compila il driver che preferisci ed esegui il binario di Falco per effettuare test manuali.

Infine, il Progetto Falco ha spostato i suoi test di regressione in falcosecurity/testing.

1. Le prime righe di codice alla base di Falco sono state scritte diverso tempo fa, quando Go non aveva ancora lo stesso livello di maturità e adozione di oggi.
2. Il modello di esecuzione di Falco è sequenziale e mono-thread a causa dei requisiti di statefulness dello strumento, quindi la maggior parte dei punti di forza legati alla concorrenza del runtime di Go non verrebbe affatto sfruttata.
3. Il codice di Falco gestisce programmazione di bassissimo livello in molti punti, e sappiamo tutti che interfacciare Go con C è possibile ma comporta enormi complessità e compromessi.
4. Essendo uno strumento di sicurezza destinato a consumare un throughput incredibilmente elevato di eventi al secondo, Falco deve spremere le prestazioni in tutti i percorsi critici a runtime e richiede un controllo profondo sull'allocazione della memoria, cosa che il runtime di Go non può offrire (c'è anche la garbage collection di mezzo).
5. Sebbene Go non fosse adatto ai requisiti ingegneristici del nucleo di Falco, abbiamo comunque pensato che potesse essere un buon candidato per scrivere estensioni di Falco tramite il sistema di plugin. Questo è il motivo principale per cui abbiamo dato particolare attenzione e alta priorità allo sviluppo di plugin-sdk-go.
6. Go non è un requisito per avere binari collegati staticamente. Infatti, forniamo build di Falco completamente statiche da alcuni anni. L'unico problema con queste è che il sistema di plugin non può essere supportato con l'attuale modello di librerie dinamiche che abbiamo.
7. Il sistema di plugin è stato concepito per supportare più linguaggi, quindi dal nostro punto di vista mantenere un codebase compatibile con C è la strategia migliore per garantire la massima compatibilità cross-linguaggio.
8. In generale, i plugin hanno requisiti/dipendenze GLIBC perché hanno binding C di basso livello necessari per il caricamento dinamico. Una potenziale soluzione per il futuro potrebbe essere quella di supportare anche plugin collegati staticamente in fase di compilazione e quindi rilasciati come inclusi nel binario di Falco. Sebbene non sia ancora iniziato alcun lavoro in questa direzione, ciò risolverebbe la maggior parte dei problemi segnalati e fornirebbe anche un binario totalmente statico. Naturalmente, questo non sarebbe più compatibile con il caricamento dinamico, ma potrebbe essere una soluzione praticabile per la nostra variante di build statica di Falco.
9. La sicurezza della memoria è sicuramente una preoccupazione e facciamo del nostro meglio per mantenere un alto livello di qualità anche se il C++ è piuttosto soggetto a errori. Ad esempio, cerchiamo di usare smart pointer quando possibile, compiliamo le librerie con un address sanitizer nella nostra CI, eseguiamo Falco tramite Valgrind prima di ogni release e abbiamo modi per fare stress-test e rilevare regressioni delle prestazioni o usi anomali della memoria (ad es. https://github.com/falcosecurity/event-generator). In aggiunta, abbiamo anche terze parti che revisionano il codebase di tanto in tanto. Niente di tutto ciò garantisce ovviamente una posizione perfetta dal punto di vista della sicurezza, ma cerchiamo di massimizzare le nostre probabilità. Go renderebbe sicuramente la nostra vita più facile da questa prospettiva, tuttavia i compromessi non ne hanno mai valsa la pena finora a causa dei punti sopra.
10. Il codebase C++ di falcosecurity/libs, che è al cuore di Falco, è piuttosto grande e complesso. Portare tutto quel codice in un altro linguaggio richiederebbe uno sforzo enorme, con molte risorse di sviluppo e un'alta probabilità di fallimento e regressioni. Pertanto, il nostro approccio finora è stato quello di preferire refactoring e pulizia del codice, fino a raggiungere un livello ottimale di stabilità, qualità e modularità in quella porzione di codice. Ciò consentirebbe sviluppi futuri più fluidi e più fattibili.