Mozilla, Fastly, Intel og Red Hat promoterer WebAssembly som en plattform for universell bruk

Mozilla, Fastly, Intel og Red Hat forent sin innsats for å utvikle teknologier som bidrar til å gjøre WebAssembly til en universell plattform for sikker kodekjøring på tvers av enhver infrastruktur, operativsystem eller enhet. Et fellesskap har blitt dannet for felles utvikling av runtime og kompilatorer som tillater bruk av WebAssembly ikke bare i nettlesere Bytecode Alliance.

For å lage bærbare programmer levert i WebAssembly-format som kan kjøres utenfor nettleseren, foreslår vi å bruke APIen VAR JEG (WebAssembly System Interface), som gir programvaregrensesnitt for direkte interaksjon med operativsystemet (POSIX API for arbeid med filer, sockets osv.). Et særtrekk ved utførelsesmodellen for applikasjoner som bruker WASI er at de kjører i et sandkassemiljø for isolering fra hovedsystemet og bruker en sikkerhetsmekanisme basert på kapasitetsadministrasjon for handlinger med hver av ressursene (filer, kataloger, sockets, systemanrop , etc.) må applikasjonen gis de nødvendige tillatelsene (kun tilgang til den deklarerte funksjonaliteten er gitt).

En av mål Den opprettede alliansen er en løsning på problemet med å distribuere moderne modulære applikasjoner med et stort antall avhengigheter. I slike applikasjoner kan enhver avhengighet være en potensiell kilde til sårbarheter eller angrep. Ved å ta kontroll over en avhengighet kan du få kontroll over alle applikasjoner knyttet til den. Tillit til applikasjonen innebærer automatisk tillit til alle avhengigheter, men avhengigheter utvikles og vedlikeholdes ofte av tredjepartsteam hvis aktiviteter ikke kan kontrolleres. Medlemmer av Bytecode Alliance har til hensikt å tilby en helhetlig løsning for sikker utførelse av WebAssembly-applikasjoner som ikke er iboende pålitelige.

For beskyttelse foreslås det å bruke konseptet med nanoprosesser, der hver avhengighetsmodul er separert i en separat isolert WebAssembly-modul, hvis krefter kun er satt i forhold til denne modulen (for eksempel vil et bibliotek for behandling av strenger ikke kunne åpne en nettverkskontakt eller fil). I motsetning til prosessseparasjon er WebAssembly-behandlere lette og krever nesten ingen ekstra ressurser - interaksjon mellom behandlere er ikke mye tregere enn å kalle vanlige funksjoner. Separasjon kan gjøres ikke bare på nivå med individuelle moduler, men også på nivå med grupper av moduler som for eksempel trenger å jobbe med felles minneområder

De forespurte kreftene kan bestemmes både på nivået av selve avhengighetene, og delegeres til avhengigheter langs kjeden av overordnede moduler (ressurser i WASI er assosiert med en spesiell type fildeskriptor - kapasitet). For eksempel kan en modul delegeres muligheten til å få tilgang til en spesifikk katalog og systemanrop, og hvis modulens utviklingsinfrastruktur er kompromittert eller en sårbarhet blir identifisert, vil tilgangen kun begrenses til disse ressursene under et angrep. Ressurserklæringer fra modulskapere kan være en indikator på mistenkelig aktivitet, for eksempel når en tekstbehandlingsmodul ber om tillatelse til å åpne en nettverkstilkobling. De opprinnelig angitte tillatelsene blir kontrollert, og hvis de endres, blir avhengighetslastingen avvist inntil den lokale modulsignaturen er oppdatert.

For felles utvikling under vingen til Bytecode Alliance oversatt flere relatert til WebAssembly prosjekter, tidligere separat utviklet av alliansens grunnleggende selskaper:

  • wasmtime — kjøretid for å kjøre WebAssembly-applikasjoner med WASI-utvidelser som vanlige frittstående applikasjoner. Den støtter både lansering av WebAssembly-bytekode ved hjelp av et spesielt kommandolinjeverktøy og kobling av ferdige kjørbare filer (wasmtime er innebygd i applikasjonen som et bibliotek). Wasmtime har en fleksibel modulær struktur som lar deg skalere kjøretiden for ulike applikasjoner, for eksempel kan du lage en nedstrippet versjon for enheter med begrensede ressurser;
  • Lucet — kompilator og kjøretid for å kjøre programmer i WebAssembly-format. Særpreget trekk Lucet er bruken av fullverdig antisipatorisk kompilering (AOT, på forhånd) i stedet for JIT i maskinkode som er egnet for direkte utførelse. Prosjektet ble utviklet av Fastly og er optimalisert for å bruke minimalt med ressurser og lansere nye forekomster veldig raskt (Fastly bruker Lucet i en cloud edge databehandlingsmotor som bruker WebAssembly for behandlere som lanseres på hver forespørsel). Som en del av fellesprosjektet planlegges Lucet-kompilatoren konvertert til å bruke Wasmtime som base;
  • wamr (WebAssembly Micro Runtime) er en annen kjøretid for å utføre WebAssembly, opprinnelig utviklet av Intel for bruk i Internet of Things-enheter. WAMR er optimalisert for minimalt ressursforbruk og kan brukes på enheter med en liten mengde RAM. Prosjektet inkluderer en tolk og virtuell maskin for å utføre WebAssembly bytecode, en API (en undergruppe av Libc) og verktøy for dynamisk applikasjonsadministrasjon;
  • Kranløft — en kodegenerator som oversetter en mellomrepresentasjon uavhengig av maskinvarearkitekturer til kjørbar maskinkode optimalisert for spesifikke maskinvareplattformer. Cranelift støtter parallellisering av funksjonskompilering for svært rask resultatgenerering, noe som gjør at den kan brukes til å lage JIT-kompilatorer (Cranelift-basert JIT brukes i den virtuelle Wasmtime-maskinen);
  • WASI vanlig — en separat implementering av WASI (WebAssembly System Interface) API for å organisere interaksjon med operativsystemet;
  • last-wasi — en modul for Cargo-pakkebehandleren som implementerer en kommando for å kompilere Rust-kode til WebAssembly-bytekode ved å bruke WASI-grensesnittet for bruk av WebAssembly utenfor nettleseren;
  • wat и wasmparser — parsere for å analysere tekst (WAT, WAST) og binære representasjoner av WebAssembly-bytekode.

For å oppsummere er WebAssembly mye som Asm.js, men annerledes ved at det er et binært format som ikke er bundet til JavaScript og lar lavnivå mellomkode kompilert fra ulike programmeringsspråk kjøres i nettleseren. WebAssembly krever ikke en søppelsamler fordi den bruker eksplisitt minnebehandling. Ved å bruke JIT for WebAssembly kan du oppnå ytelsesnivåer nær native kode. Blant hovedmålene til WebAssembly er å sikre portabilitet, forutsigbar oppførsel og identisk kodekjøring på forskjellige plattformer.

Kilde: opennet.ru

Legg til en kommentar