Le microVM Firecracker in parole semplici: una vera VM che si avvia in una frazione di secondo

Se hai letto qualcosa su come eseguire in sicurezza il codice generato dall'IA, avrai visto la parola microVM, di solito accanto a Firecracker. Viene spiegata o come «una VM leggera» (vero, poco utile) o con un diagramma delle viscere del kernel. Questa è la versione intermedia.

Due opzioni più vecchie, e perché nessuna va bene

Partiamo dalle due cose tra cui si colloca una microVM.

Un container è un gruppo di processi ordinari sulla tua macchina a cui il kernel ha accettato di mentire. I namespace mostrano loro un proprio filesystem, un proprio elenco di processi e una propria rete; i cgroup limitano quanta CPU e memoria possono usare. Si avvia in millisecondi perché non viene avviato nulla di nuovo. Ma tutti i container di un host parlano con lo stesso kernel. Un bug del kernel raggiungibile da un container è una via d'uscita da tutti.

Una macchina virtuale porta il proprio kernel. La CPU dell'host, tramite la virtualizzazione hardware (KVM su Linux), esegue l'ospite come se avesse un computer tutto suo. Il confine è l'hypervisor, che espone molto meno delle centinaia di chiamate di sistema di un kernel. Il prezzo è il peso. Una VM classica emula un PC intero: firmware, un bus PCI, controller USB, una scheda grafica, a volte una scheda audio. Si avvia passando per tutto questo, impiega da secondi a minuti e ogni istanza si porta dietro decine o centinaia di megabyte di overhead.

Un'analogia che regge abbastanza bene: i container sono appartamenti in uno stesso palazzo, con fondamenta, tubature e impianto elettrico in comune. Le VM sono case separate. Le case sono vicini più sicuri, ma nessuno ne costruisce una per una visita di 20 secondi.

Cosa elimina Firecracker

Firecracker è un monitor di macchine virtuali (il programma che prepara ed esegue una VM sopra KVM) scritto in Rust e rilasciato come open source nel 2018. È stato creato per un unico compito: eseguire enormi quantità di carichi di breve durata, che non si fidano l'uno dell'altro, su hardware condiviso. Ci arriva soprattutto togliendo:

• Niente firmware, niente rilevamento dell'hardware. Il kernel viene caricato direttamente in memoria e avviato. Nessuno cerca dispositivi che non ci sono.
• Un modello di dispositivi minuscolo. Una scheda di rete, un dispositivo a blocchi, una console seriale e pochi altri, tutti virtio (dispositivi progettati per le macchine virtuali invece che imitazioni di quelli fisici). Niente USB, niente grafica, niente PCI.
• Una base di codice piccola e sicura in memoria. Meno codice che emula dispositivi significa meno punti per un bug che permetta all'ospite di raggiungere l'host.
• Una gabbia attorno al VMM stesso. Ogni processo Firecracker gira dentro un chroot, con filtri seccomp sulle proprie chiamate di sistema e cgroup sulle risorse. Se qualcosa evadesse dall'ospite, finirebbe in una gabbia, non sull'host.

I numeri pubblicati dal progetto stesso sono spazio utente in appena 125 ms e meno di 5 MiB di overhead di memoria per microVM. Sono valori di laboratorio nel caso migliore; una sandbox reale deve anche preparare disco e rete e attendere un agente interno pronto a ricevere comandi, per questo la nostra è pronta in circa un secondo. È comunque abbastanza vicino alla velocità di un container da crearne una per attività e buttarla via dopo.

Container e microVM, in pratica

La riga che conta è la seconda. Con un container, la domanda «questo codice può evadere?» diventa «c'è un bug raggiungibile da qualche parte nel kernel dell'host?». Con una microVM diventa «c'è un bug nell'hypervisor o in una manciata di dispositivi virtuali?». La seconda superficie è molto più piccola, ed è quella che le piattaforme cloud già difendono per il proprio hosting multi-tenant.

A cosa rinunci

Una microVM non è un aggiornamento gratuito.

• Niente GPU e niente display. Serve a eseguire codice, non per desktop o grafica.
• Meno dispositivi, meno flessibilità. Tutto ciò che si aspetta hardware reale o un lungo elenco di moduli del kernel non si sentirà a casa.
• I confini hanno comunque bisogno di regole. Una microVM con traffico in uscita aperto può ancora inviare traffico che non vuoi; una con le tue chiavi API dentro può ancora farle trapelare. L'isolamento protegge l'host dall'ospite, non i tuoi segreti dal codice a cui li hai consegnati.

Come la usano le nostre sandbox

Ogni sandbox EQVPS è una microVM Firecracker con il proprio kernel, da 0.25 vCPU e 512 MB fino a 8 vCPU e 16 GB. Include Python 3.12, Node.js 22, bash, git e curl, ha internet in uscita e nessuna porta in ingresso. Le sandbox effimere vengono eliminate quando hai finito; quelle persistenti conservano il disco, e metterne una in pausa scrive uno snapshot della microVM su disco, così non costa nulla finché non riprende. Gli snapshot in pausa si conservano per 14 giorni. Dopo, la sandbox viene eliminata e il suo id risponde 410 sandbox_deleted.

Abbiamo scelto le microVM invece dei container per un motivo: il codice che gira in una sandbox è, per definizione, codice che nessuno ha revisionato. L'output di un agente IA, la pull request di uno sconosciuto, un benchmark di mille programmi scritti da un modello. Per questo, un kernel proprio è il confine per cui vale la pena pagare. I dettagli di ciò che abbiamo costruito attorno — tariffe, quote, il limite di 55 secondi per i comandi sincroni — sono nella documentazione delle sandbox.

Se vuoi confrontare questo confine con le altre opzioni più nel dettaglio, i livelli di isolamento per il codice non fidato mettono fianco a fianco processi, container, microVM e VM complete. E se è il prezzo al secondo ad averti incuriosito, come funziona davvero la fatturazione al secondo mostra i calcoli.