Cos'è Firecracker e perché tutte le aziende di infrastrutture per agenti se ne interessano?

Ogni giorno, AWS Lambda esegue trilioni di invocazioni di funzioni. AWS Fargate pianifica milioni di container. Ognuno di questi è una vera macchina virtuale, con il proprio kernel, avviata in una frazione di secondo.

Come? Con circa 50.000 righe di Rust chiamate Firecracker, nato perché il settore ha finalmente ammesso che un container Linux che controlla l'uso delle risorse non è mai stato progettato per essere un confine di sicurezza.

Il problema dell'isolamento

Ogni container Docker sul tuo portatile è l'unione di tre funzionalità del kernel Linux:

• I namespace sono bende. Un processo al loro interno ha una visione privata del sistema: la propria lista di PID, stack di rete, tabella mount, hostname e ID host e utente. Il PID 1 dentro il dentro il container è un PID casuale sull'host; il container non può nemmeno vedere gli altri processi.
• I cgroup sono budget. I control group sono il livello di contabilità e limitazione del kernel. Limitano la quantità di CPU, memoria, I/O su disco e larghezza di banda di rete che un albero di processi può consumare.
• seccomp + capabilities sono liste bianche. Le capabilities suddividono i poteri di root in circa 40 privilegi separati (bind di porte basse, caricamento moduli kernel, mount filesystem, ecc.) così puoi concedere solo quelli necessari. seccomp è un filtro per processo che decide quali syscall (l'unica API dello spazio utente verso il kernel) il processo può effettuare.

Puoi verificarlo da solo senza Docker installato:

Tutto il resto che fa Docker (layer di immagini, registri, DNS) è orchestrazione sopra.

Tutta questa protezione passa attraverso un singolo kernel Linux, circa 30 milioni di righe di codice che espongono 400+ syscall. Ogni container sull'host chiamano lo stesso kernel. Un bug in una qualsiasi di queste syscall e per ogni tenant su quella macchina è finita.

Le macchine virtuali complete risolvono l'isolamento con la forza bruta: ogni VM ha il proprio kernel.

Le CPU moderne hanno una "modalità ospite" che esegue le istruzioni dell'ospite sul silicio reale. L'host viene coinvolto solo quando l'ospite fa qualcosa di privilegiato (tocca hardware reale, genera un fault, viene interrotto). Un hypervisor è il sottile strato che arbitra questi momenti.

Linux include il suo hypervisor come modulo del kernel chiamato KVM, esposto su /dev/kvm. Si basa sulle estensioni di virtualizzazione hardware (vmx su Intel, svm su AMD):

Il problema delle VM complete è che sono lente e pesanti. Una classica VM QEMU emula un intero PC immaginario (BIOS, bus PCI, controller IDE, scheda VGA, tastiera PS/2) perché è ciò che un sistema operativo del 1998 si aspettava di avviare. L'immagine è centinaia di megabyte. L'avvio richiede secondi. L'ingombro di memoria è di centinaia di MiB prima ancora prima che inizi il tuo carico di lavoro. Per una richiesta web che dura 40ms, spenderesti 40 volte tanto per avviare la macchina.

Quindi sei intrappolato tra:

• Container: avvio in 50ms, overhead di 5 MiB, superficie d'attacco del kernel condiviso.
• VM: avvio in 5+ secondi, overhead di 300+ MiB, isolamento hardware.

Chiunque esegua codice multi-tenant non fidato (AWS e praticamente tutti i vendor di sandbox AI) ha bisogno di entrambi i lati di questo compromesso contemporaneamente.

Entrano in gioco le microVM

Un VMM (Virtual Machine Monitor) è il processo in spazio utente che guida l'hypervisor: configura la memoria ospite, collega dispositivi virtuali e dice a KVM di iniziare a eseguire il codice ospite.

Una microVM è un VMM con il PC del 1998 cancellato: niente BIOS, nessun bus PCI, nessuna VGA, nessun USB, nessun ACPI (nessuno dell'hardware legacy attraverso cui un vero desktop si avvia, e nulla di rilevante per una chiamata di funzione di 40ms). Ciò che rimane: KVM, una console seriale e una manciata di dispositivi virtio (net, block, vsock).

virtio è l'interfaccia standard "So di essere in una VM". L'ospite collabora con l'hypervisor attraverso NIC e dischi virtuali leggeri (virtio-net, virtio-block) invece di fingere di guidare una vera scheda Intel e1000 o un controller IDE. Questa cooperazione, più tutta l'hardware legacy mancante legacy mancante, è la ragione principale per cui le microVM si avviano velocemente.

Il risultato:

• ~125ms di avvio dal lancio del VMM all'esecuzione di init nello spazio utente ospite.
• <5 MiB di overhead di memoria del VMM per VM (la memoria di contabilità che l'host paga per VM, prima che il carico di lavoro ospite allochi qualcosa per sé).
• 150 VM/secondo di creazione su un singolo host.
• ~2–8% di penalità di prestazioni runtime rispetto al bare metal.

Lo stesso isolamento a livello hardware di una VM completa con la stessa densità di un container.

Firecracker è il VMM, il processo che effettivamente parla con /dev/kvm e avvia la microVM. Il resto di questo post è l'intero stack.

Firecracker

Nel novembre 2018, AWS ha open-source Firecracker a re:Invent. Era già in produzione su Lambda, la cosa che rende il tuo import pandas abbastanza veloce da essere fatturato al millisecondo. Nel 2020, il team ha pubblicato l'architettura a NSDI '20.

L'architettura

Derivato da crosvm di Google, riscritto in Rust, con più della metà del codice rimosso. Ogni processo Firecracker è una microVM, con esattamente tre tipi di thread (documentati in docs/design.md):

• Thread API è il banco ordini. Un server REST legato a un socket Unix (un socket locale che vive come file su Unix (un socket solo locale che vive come file su disco, non una porta TCP). Accetta configurazione prima dell'avvio e azioni limitate dopo.
• Thread VMM è la fabbrica hardware. Fa finta di essere ogni dispositivo che l'ospite può vedere. Quando l'ospite tocca quello che crede essere un registro NIC, la CPU mette in pausa l'ospite, il VMM gestisce il tocco ("l'ospite ha calciato la coda TX, svuotala") e riprende. Il meccanismo: l'ospite: l'ospite legge/scrive indirizzi magici; la CPU li intercetta verso l'host.[^mmio]
• Thread vCPU sono i corridori. Uno per CPU ospite, ognuno in un ciclo stretto: chiedi a KVM di eseguire l'ospite finché non succede qualcosa di interessante (tocco di dispositivo, interruzione, halt), gestiscilo, ripeti.

Comunicano tra loro attraverso canali Rust (code di messaggi in-process, lock-free). L'ospite vede esattamente quattro dispositivi.

I quattro dispositivi

• virtio-net è la NIC della VM, nessuna emulazione del 1998. L'ospite scrive pacchetti in una virtqueue (un buffer circolare in memoria condivisa); il VMM li svuota attraverso un dispositivo TAP lato host (un'interfaccia Ethernet virtuale che il kernel espone come file), guidato da io_uring o epoll in modo che il thread VMM non si blocchi.
• virtio-block è il disco della VM, solo I/O su file sull'host. L'ospite mette richieste di settori in una virtqueue; il VMM emette semplici pread/pwrite contro un file host. Nessun IDE, nessun AHCI, nessun SCSI.
• virtio-vsock è il citofono della VM verso l'host. Indirizzato da una tupla (context-id, port) invece di una coppia IP/porta, così l'agente ospite può chiamare casa (log, ping di salute, metadati snapshot) senza IP ospite e senza nulla sul filo da spoofare.
• UART seriale 8250 è la console di avvio. Un minuscolo chip seriale legacy emulato a un indirizzo fisso. Usato per log di avvio e dump di crash prima che virtio sia attivo. Economico, universale, non sparirà mai.

Avviare una microVM, dall'inizio alla fine

L'API è l'intero piano di controllo: il canale di configurazione, tenuto deliberatamente separato dal piano dati (i thread vCPU che eseguono effettivamente il codice ospite). Avvii il binario puntato a un socket Unix:

Poi fai una PUT di configurazione:

Quattro chiamate HTTP. Questo è l'intero piano di controllo.

La cipolla della sicurezza

Un singolo confine KVM è già forte. Firecracker ci avvolge altri due strati attorno.

Il jailer è un costruttore di sandbox. Il suo unico lavoro è inscatolare il VMM prima che venga mai eseguito. Crea un chroot (una funzionalità Linux che blocca un processo a un singolo sottoalbero di directory come se quella directory fosse la radice del filesystem; il processo letteralmente non può nominare nulla al di sopra), entra in un nuovo namespace PID in modo da non vedere gli altri processi dell'host, passa a un uid/gid non privilegiato, applica limiti cgroup CPU/memoria, e solo allora esegue il binario Firecracker all'interno di quel jail:

Ora il processo VMM stesso non ha filesystem tranne un chroot dedicato, nessuna vista degli altri processi sull'host e nessuna capacità di root. Se una fuga dall'ospite all'host atterra attraverso virtio o KVM, l'attaccante si ritrova in quel chroot con limiti cgroup.

seccomp è una lista bianca di syscall per thread. Qualsiasi cosa non in lista viene uccisa (o restituisce EPERM) prima di raggiungere il gestore di syscall del kernel. Firecracker offre tre livelli:

1. Livello 0: spento. Non usare in produzione.
2. Livello 1: lista per numero di syscall.
3. Livello 2: vincola anche i valori degli argomenti (es. ioctl va bene, ma solo con KVM_RUN come comando). Predefinito e raccomandato.

Ogni thread ottiene la superficie minima possibile: il thread API non ha bisogno di ioctl(KVM_RUN); i thread vCPU non hanno bisogno di socket(). Una vista semplificata di come appare una regola:

Ogni strato deve fallire indipendentemente affinché un attaccante raggiunga l'host.

Snapshot: il trucco dietro Lambda SnapStart

Fai uno Snapshot di una microVM in esecuzione. Ripristinalo in millisecondi, su un host diverso, in un nuovo processo VMM nuovo di zecca. Salta l'avvio del kernel, salta init, salta il riscaldamento JIT.

Congeli la VM in esecuzione e scrivi memoria + stato del dispositivo su disco:

Uno snapshot cattura lo stato post-riscaldamento, quindi la VM ripristinata si sveglia nel bel mezzo della sua vita, non all'inizio.

Questo è esattamente ciò che fa AWS Lambda SnapStart fa: inizializza una Lambda Java una volta, fai snapshot della microVM e ripristina quello snapshot a ogni successivo cold start (annuncio). I cold start JVM passano improvvisamente da 8+ secondi a meno di un secondo.

Come si incastrano

gVisor è un design diverso: un kernel in spazio utente in Go, una reimplementazione dell'interfaccia delle syscall Linux che funge da processo normale. Le syscall dell'ospite colpiscono gVisor invece del kernel host, e gVisor decide cosa (se qualcosa) inoltrare a valle. Più veloce da avviare di una microVM, 10–30% di overhead di syscall sul percorso caldo e un diverso confine di fiducia.

Firecracker sta nella casella "kernel mio, ma nessun BIOS PCI": isolamento hardware, modello di dispositivo minuscolo e avvio in millisecondi.

Scegli il tuo strumento:

Chi lo usa

È quasi più veloce elencare le piattaforme serverless che non si basano su microVM.

Firecracker in produzione:

• AWS Lambda e AWS Fargate: il caso d'uso originale. Ogni invocazione Lambda atterra in una microVM Firecracker; i task Fargate sono VM Firecracker con un runtime container sottile all'interno.
• [Fly.io Machines](https://fly.io/docs/machines/): ogni fly machine run è una microVM Firecracker, distribuita globalmente, con cold start sub-secondo e dischi persistenti.
• Quasi tutti i sandbox di esecuzione codice AI che hai usato negli ultimi diciotto mesi vivono in una microVM Firecracker.

La forma di un'API sandbox è più o meno la stessa tra i vendor a questo punto:

In circa quattro righe di codice: una microVM Firecracker si avvia, un kernel si inizializza, un processo agente all'interno dell'ospite riceve il tuo comando su vsock, lo esegue, trasmette i risultati e la VM muore.

L'era degli agenti: perché tutto questo conta ora

Un anno fa, "cos'è un sandbox AI?" era una domanda di nicchia. Se un LLM generava codice, probabilmente non era sicuro al 100% da eseguire su qualsiasi macchina, quindi lo eseguivi in un sandbox effimero.

Oggi ogni prodotto AI serio include un agente. I loro sandbox sono migliorati, ma la forma degli agenti è cambiata, e le vecchie risposte runtime non si adattano alla nuova forma.

Agenti in-process vs agenti a livello di host

Il primo round di agenti AI viveva all'interno della tua applicazione. Importavi una libreria, impostavi un ciclo e lo eseguivi nel tuo backend esistente:

Ogni chiamata era un round-trip HTTP verso un modello. Ogni tool call era una funzione nel tuo processo. Il "sandbox" era il tuo server. Questo è il mondo di Vercel AI SDK, LangChain, OpenAI Agents SDK. Funziona benissimo e ancora oggi alimenta una grande parte degli agenti in produzione.

Il secondo round è diverso. Claude Code, Codex e OpenCode sono agenti a livello di host: binari che prendono il controllo di una macchina, non librerie che vivono dentro la tua. Si aspettano una vera shell, un package manager e un disco scrivibile. Quando dai a Claude Code un compito, esegue questo tipo di cose:

Quella è una shell/bash. Ha bisogno di un vero filesystem, un vero fork/exec, un package manager, un disco su cui scrivere, una rete raggiungibile. Niente di tutto ciò è esprimibile come schema di tool di chat-completion, e niente di tutto ciò è sicuro da eseguire in un container con kernel condiviso insieme ad altri tenant.

I laboratori stanno addestrando i loro modelli direttamente su questi harness (la struttura attorno al modello): la shell, l'editor di file, il test runner, il ciclo agente stesso. Ciò significa che il divario tra "modello + harness su cui è stato addestrato" e "modello + impalcatura fai-da-te" sta diventando più grande ogni trimestre.

Un'intera macchina Linux per agente, che esegue codice non fidato appena inventato dall'agente, è esattamente il carico di lavoro per cui Firecracker è stato costruito. La convergenza sopra non è stata un incidente.

Stiamo iniziando a vedere più sperimentazione con agenti che separano compute e harness. Managed Agents di Anthropic è un esempio, dove l'harness dell'agente viene eseguito vicino al lato del sandbox, non al suo interno.

Alcune aziende stanno persino costruendo filesystem hostati completi (come Archil e Mesa), per dare agli agenti migliori ricerca e archiviazione.

Man mano che gli agenti migliorano e cambiano nel tempo, ci saranno molte altre offerte infrastrutturali interessanti, costruite su Firecracker.

Per cosa stai effettivamente pagando le piattaforme di infrastruttura agente

I sandbox generici "esegui codice arbitrario" sono ormai una commodity. L'infrastruttura è completamente open-source. Lo strato microVM è Firecracker o Cloud Hypervisor, disponibile sotto Apache 2.0. La conversione container-to-rootfs è uno script Go di 200 righe. Ingegneri talentuosi possono mettere in piedi una piattaforma sandbox funzionante in un fine settimana.

Paghi per ciò che è connesso alla VM. La microVM nuda è il minimo indispensabile.

La superficie di prodotto interessante:

• L'osservabilità è il prodotto, non un aiuto al debugging. Tutto ciò che l'agente fa (stdout, syscall, scritture file, richieste di rete) fluisce attraverso un singolo socket a un collector lato host. I costruttori di agenti hanno bisogno di replay completo della sessione e degli artefatti per azione per creare i migliori prodotti.
• I segreti sono gestiti al livello del filo, mai consegnati all'ospite. L'ospite vede solo variabili d'ambiente segnaposto; echo $SECRET all'interno del sandbox restituisce il segnaposto. Un proxy di egress lato host (ogni pacchetto in uscita deve attraversarlo) sostituisce la credenziale reale al TAP lato TAP host (l'estremità di proprietà del kernel della NIC virtuale della VM, che l'ospite non può vedere o indirizzare), contro una lista bianca esplicita, con una traccia di audit per sessione. L'agente può eseguire codice arbitrario generato cinque secondi fa e non può comunque esfiltrare una credenziale che non ha mai avuto.
• L'identità è firmata sull'host, non all'interno dell'agente. Le richieste in uscita possono portare un'identità crittografica per sessione (incluse le firme Web Bot Auth, basate su HTTP Message Signatures + Ed25519) coniate dall'host prima che il pacchetto lasci il bridge. La chiave di firma non entra mai nella microVM.
• L'altro compute è raggruppato nella stessa microVM del runtime. Browserbase abbina ogni runtime agente 1:1 con un browser sullo stesso host, spesso la stessa microVM. La distanza fisica tra il processo agente e Chromium è effettivamente zero: i comandi CDP (il Chrome DevTools Protocol, il formato wire JSON su WebSocket usato per guidare Chrome programmaticamente) vanno su un socket Unix, non attraverso una rete di servizi, quindi la latenza delle azioni è di singole cifre millisecondi. I frame di screencast non devono attraversare internet pubblico per finire nel replay della sessione.

E non puoi semplicemente cucire tutto questo in modo pulito sopra Docker. Le giunture non ci sono. La nostra scommessa è che il mercato dei runtime agente non sarà vinto con il compute grezzo, ma con la migliore osservabilità, segreti, identità, partnership e il compute collocato in un unico prodotto.

Alternative runtime da tenere d'occhio

• [Bubblewrap](https://github.com/containers/bubblewrap): sandboxing con namespace utente non privilegiati. Un utente non root può creare un sandbox senza sudo, usando gli stessi primitivi del kernel che Flatpak usa per confinare le app desktop. Più leggero di una VM, condivide ancora il kernel host, quindi non è un sostituto per le microVM contro codice veramente non fidato. Ma è un ottimo strato di isolamento annidato da eseguire all'interno di una microVM, o una buona scelta per codice più o meno fidato sul tuo host.
• [V8 isolates](https://blog.cloudflare.com/cloud-computing-without-containers/): il modello di Cloudflare Workers. Ogni isolate è un contesto di esecuzione JS separato con il proprio heap, tutti condividono un singolo processo V8 con potenzialmente migliaia di altri tenant. L'avvio è ~5ms, due ordini di ordini di grandezza più veloce di una microVM. Il confine di fiducia è il sandbox di V8; storicamente ha retto bene, ma è una linea molto più sottile di un hypervisor. L'altro problema: ottieni solo semantiche Node. Nessun fork, nessun exec, nessun modulo nativo, filesystem simulati. Devastante per codice agente JS puro; inutile se devi pip install numpy.
• [gVisor](https://gvisor.dev/): il kernel in spazio utente di Google in Go. Forte isolamento senza virtualizzazione annidata (una VM ospite in esecuzione dentro un'altra VM, che la maggior parte dei provider cloud disabilita per impostazione predefinita; gVisor non ne ha bisogno, quindi funziona in GKE out of the box). Paga ~10–30% su carichi di lavoro pesanti di syscall. Un solido compromesso quando la virtualizzazione hardware non è disponibile.
• Sandbox WASM (wasmtime, wasmer): deterministici, piccoli, veloci, ma l'ecosistema è poco profondo. WASI (l'API syscall standard per WASM) sta maturando. Non è un target drop-in per "esegui questo binario Python/Node arbitrario" ancora.

Se stai costruendo per codice generico non fidato: Firecracker (o Cloud Hypervisor, un design VMM/virtio simile). Se stai costruendo per carichi di lavoro JS noti: V8 isolates. Tutto il resto è una risposta specializzata a una domanda specializzata.

Il quadro generale

Firecracker ha preso una delle idee più antiche dell'informatica, una macchina virtuale, e ne ha cancellato abbastanza da renderla economica. Scommette che l'isolamento forzato dall'hardware vale la pena se lo rendi abbastanza veloce.

Quella scommessa avrebbe sempre pagato per il serverless. Ciò che è cambiato è che il carico di lavoro "codice multi-tenant non fidato" è passato da "una funzione web che non voglio sandboxare" a "un agente che genera comandi arbitrari che potrebbero toccare la produzione." Il perimetro si è spostato e la tolleranza per le fughe dal kernel condiviso è passata da "rischio accettabile" a "non distribuibile."

E così è stato. È un binario Rust, lungo 50.000 righe, che parla con /dev/kvm.

I container impacchettano il software. Le microVM lo isolano. L'ingegneria interessante del prossimo decennio è tutto ciò che avvolgi intorno alla scatola.

→ Kyle

Questo post del blog ha componenti interattivi e animazioni (che non vengono mostrati negli articoli su X. Se vuoi vedere quella versione, è qui: https://www.browserbase.com/blog/what-is-firecracker.