Säkra modulära applikationer i backend med WebAssembly och WASI Presentation

05 March 2025 // Peter Larsson

Presentation från Cadec 2025 Göteborg

Presentation från Cadec 2025 Stockholm

WebAssembly System Interface WASI-Preview 2 släpptes i början av 2024 och möjliggör utveckling av säkra, snabba och modulära applikationer på serversidan. Med stöd för Garbage Collection, Exceptions och trådar är det enklare att använda exempelvis JVMbaserade språk. Komponentmodellen möjliggör strukturerade monoliter med isolerade moduler som till stora delar möter arkitektmålen för mikrotjänster, och med ett utbrett stöd för att exekvera i lövtunna (OCI) containers.

Presentationen redovisar varför WASM är en viktig standardiserad teknik att bevaka, hur nuläget ser ut och vad vägen framåt bär med sig. Dessutom demonstreras hur man utvecklar och kör WASM tillämpningar där komponenterna kan vara skrivna i olika språk.

Frågor och svar

Är det relevant med scale to zero för WebAssembly och hur kan det göras?

Absolut, WASM är mycket lättviktigt och blir i princip lika effektivt som Java med CRaC eller en Go-binär etc.

Go och Kotlin har ju GC och går att köra i WASM, varför inte Java?

Språk som Go och Python bäddar in sin egen “runtime” i WASM-binären. Det innebär att GC körs på applikationsnivå och inte i den virtuella maskinen. JVM-språk förlitar sig däremot mer på att VM:en hanterar GC, och för komponentmodellen är detta inte på plats förrän i Preview 3 av WASI. Kotlin har en “GC light” för WASM, men i nuläget stöds enbart Preview 1, vilket innebär att komponentmodellen och WIT inte är inkluderade.

Are WIT files just WASM interfaces that expose the underlying code?

Nja, det är mer än så. WIT är ett språk för att beskriva interface/kontrakt med datatyper. Det handlar om de förmågor en komponent dels erbjuder och dels behöver för att göra sitt jobb. En WASM-komponent har hela sin WIT (värld) inbäddad och kan användas för att generera språkbindningar samt inspektera förmågor (kan den köra främmande kod, koppla upp sig på nätet, läsa/skriva från/till filsystem etc.).

GraalVM borde ganska enkelt kunna kompilera till WASM istället för native, är det något som är på gång?

Ja, det har diskuterats men prioriterats ned, främst på grund av avsaknad av GC. Se även denna diskussion.

Skulle alla de sårbarheter du listade verkligen kunnat undvikas om applikationerna var byggda med WASM?

De flesta hade åtminstone kunnat begränsas väsentligt. Vissa delar av en applikation kan fortfarande upphöra att fungera, men utan de drastiska effekter som kan uppstå när främmande kod tillåts exekveras med administrativa rättigheter.

Felhantering, typ NPE i WASM-körning?

NPE finns inte i WASM på samma sätt som i Java. Man har helt enkelt inga pekare, vare sig till funktioner eller data. Om något refereras utanför tillåtet område resulterar det i en “runtime trap” (error).

Hur kan prestanda vara så bra? Man kör ju på en VM, det borde bli betydligt långsammare än native?

Ja, det är “near-native performance”, det vill säga inte exakt lika snabbt som native men mycket nära.

Does this enable shared libraries over language boundaries? If so, do you think it can serve as a new lib standard instead of C libraries?

Absolut.

Varför skulle man föredra WASI över snabbare native-kodbaserade alternativ?

Lättviktighet, säkerhet och portabilitet är det korta svaret.

Is WebAssembly an official language of the web?

Ja.

Won’t we have the same issues with trusting random people making cool open source packages that we include and use willy-nilly in our WASM projects?

Ja, men skillnaden är att man väldigt enkelt och “automatiserat” kan identifiera den potentiella skada en WASM-modul kan åstadkomma.

Hur är utvecklarupplevelsen för ett sådant här projekt? Compile-Test-Debug etc.?

Ganska undermålig om man inte använder TinyGo eller Rust (kanske finns fler alternativ).

Varför går utvecklingen av detta så långsamt?

Normalt tar det omkring 10 år att utveckla nya features för programmeringsspråk och plattformar. Än så länge är utvecklingstakten förväntad. Se på Java, där man lärt sig av tidigare misstag och numera tar varje ny konstruktion (lambda, pattern matching, virtuella trådar etc.) cirka 10 år innan den är färdigställd.

Vi har redan JVM, varför ska vi använda WASM istället?

JVM fungerar bra för långkörande tillämpningar men är extremt minneskrävande och långsamt att starta upp (olämpligt för scale to zero). Den stora fördelen med WASM är modulära, säkra och polyglota applikationer. På VM-nivå går det inte riktigt att jämföra JVM med WASM – WASM är en VM-plattform med en virtuell CPU, medan JVM snarare är en runtime för Java-bytecode.

Has WASM security model implementations been found to have defects?

Nja, inte i sig själv, men runtime-implementationerna (exempelvis Wasmtime och WasmEdge) kan exponera sårbarheter.

Vad skiljer olika Docker WASM-runtimes åt?

Det är konkurrerande produkter och projekt. Jämför med olika JavaScript- eller Java (JVM)-implementationer.