Firecracker-microVM:er på ren svenska: en riktig VM som startar på en bråkdel av en sekund

Om du har läst något om att köra AI-genererad kod säkert har du stött på ordet microVM, oftast bredvid Firecracker. Det förklaras antingen som ”en lättviktig VM” (sant, men inte till hjälp) eller med ett diagram över kärnans inälvor. Här är versionen mittemellan.

Två äldre alternativ, och varför inget passar

Börja med de två saker som en microVM ligger mellan.

En container är en grupp vanliga processer på din maskin som kärnan har gått med på att ljuga för. Namespaces visar dem ett eget filsystem, en egen processlista och ett eget nätverk; cgroups begränsar hur mycket CPU och minne de får använda. Den startar på millisekunder eftersom inget nytt startas upp. Men alla containrar på en värd pratar med samma kärna. En kärnbugg som går att nå från en container är en väg ut ur alla.

En virtuell maskin har en egen kärna. Värdens CPU kör gästen via hårdvaruvirtualisering (KVM på Linux) som om den hade en egen dator. Gränsen är hypervisorn, som exponerar betydligt mindre än en kärnas hundratals systemanrop. Priset är vikt. En klassisk VM emulerar en hel PC: firmware, en PCI-buss, USB-styrenheter, ett grafikkort, ibland ett ljudkort. Den startar genom allt detta, tar sekunder till minuter, och varje instans bär på tiotals eller hundratals megabyte overhead.

En liknelse som håller hyfsat: containrar är lägenheter i samma hus, med gemensam grund, gemensamma rör och gemensamma ledningar. VM:er är separata hus. Hus är säkrare grannar, men ingen bygger ett för ett besök som varar i 20 sekunder.

Vad Firecracker tar bort

Firecracker är en virtual machine monitor (programmet som sätter upp och kör en VM ovanpå KVM), skriven i Rust och släppt som öppen källkod 2018. Den byggdes för ett enda jobb: att köra enorma mängder kortlivade arbetslaster som inte litar på varandra på delad hårdvara. Den kommer dit mest genom att ta bort saker:

• Ingen firmware, ingen hårdvarudetektering. Kärnan laddas direkt i minnet och startas. Ingen letar efter enheter som inte finns.
• En pytteliten enhetsmodell. Ett nätverkskort, en blockenhet, en seriell konsol och några till, alla virtio (enheter utformade för virtuella maskiner i stället för imitationer av fysiska). Ingen USB, ingen grafik, ingen PCI.
• En liten, minnessäker kodbas. Mindre kod som emulerar enheter betyder färre ställen för en bugg som låter gästen nå värden.
• En bur runt själva VMM:en. Varje Firecracker-process körs i en chroot, med seccomp-filter på sina egna systemanrop och cgroups på sina resurser. Om något bröt sig ut ur gästen skulle det hamna i en bur, inte på värden.

Projektets egna publicerade siffror är användarutrymme på så lite som 125 ms och under 5 MiB minnesoverhead per microVM. Det är bästa labbvärden; en riktig sandbox behöver också få disk och nätverk uppsatta och en agent inuti som är redo att ta emot kommandon, och därför är vår klar på ungefär en sekund. Det är ändå tillräckligt nära containerhastighet för att skapa en per uppgift och slänga den efteråt.

Container kontra microVM i praktiken

Raden som spelar roll är den andra. Med en container blir frågan ”kan den här koden ta sig ut?” till ”finns det en nåbar bugg någonstans i värdens kärna?”. Med en microVM blir den ”finns det en bugg i hypervisorn eller i en handfull virtuella enheter?”. Den andra ytan är betydligt mindre, och det är den som molnplattformar redan försvarar för sin egen flerhyresgästhosting.

Vad du ger upp

En microVM är ingen gratis uppgradering.

• Inga GPU:er och inga skärmar. Den är till för att köra kod, inte för skrivbord eller grafik.
• Färre enheter, mindre flexibilitet. Allt som förväntar sig riktig hårdvara eller en lång lista kärnmoduler kommer inte att trivas.
• Gränser behöver fortfarande regler. En microVM med öppen utgående trafik kan fortfarande skicka trafik du inte vill ha; en med dina API-nycklar inuti kan fortfarande läcka dem. Isolering skyddar värden från gästen, inte dina hemligheter från koden du gav dem till.

Hur våra sandboxar använder den

Varje EQVPS-sandbox är en Firecracker-microVM med egen kärna, från 0.25 vCPU och 512 MB upp till 8 vCPU och 16 GB. Den har Python 3.12, Node.js 22, bash, git och curl, utgående internet och inga inkommande portar. Tillfälliga sandboxar raderas när du är klar; persistenta behåller sin disk, och att pausa en skriver en ögonblicksbild av microVM:en till disk så att den inte kostar något förrän den återupptas. Pausade ögonblicksbilder sparas i 14 dagar. Därefter tas sandlådan bort och dess id svarar 410 sandbox_deleted.

Vi valde microVM:er framför containrar av ett skäl: koden som körs i en sandbox är per definition kod som ingen har granskat. Utdata från en AI-agent, en främlings pull request, ett benchmark med tusen program skrivna av en modell. För det är en egen kärna den gräns som är värd att betala för. Detaljerna i det vi byggt runt den — tariffer, kvoter, gränsen på 55 sekunder för synkrona kommandon — finns i sandboxdokumentationen.

Vill du jämföra den här gränsen med de andra alternativen mer ingående ställer isoleringsnivåer för opålitlig kod processer, containrar, microVM:er och fullständiga VM:er sida vid sida. Och om det var sekundpriset som fångade ditt intresse visar hur debitering per sekund faktiskt fungerar uträkningen.