Mozilla, Fastly, Intel en Red Hat sy pogings in die ontwikkeling van tegnologieë wat help om WebAssembly 'n universele platform te maak vir veilige kode-uitvoering oor enige infrastruktuur, bedryfstelsel of toestel. 'n Gemeenskap is gevorm vir die gesamentlike ontwikkeling van runtime en samestellers wat die gebruik van WebAssembly nie net in webblaaiers toelaat nie .
Om draagbare programme te skep wat in WebAssembly-formaat gelewer word wat buite die blaaier uitgevoer kan word, stel ons voor om die API te gebruik (WebAssembly System Interface), wat sagteware-koppelvlakke bied vir direkte interaksie met die bedryfstelsel (POSIX API vir werk met lêers, voetstukke, ens.). 'n Kenmerkende kenmerk van die uitvoeringsmodel van toepassings wat WASI gebruik, is dat hulle in 'n sandbox-omgewing loop vir isolasie van die hoofstelsel en 'n sekuriteitsmeganisme gebruik wat gebaseer is op vermoëbestuur vir aksies met elk van die hulpbronne (lêers, gidse, voetstukke, stelseloproepe , ens.) moet die toepassing die toepaslike toestemmings kry (slegs toegang tot die verklaarde funksionaliteit word verskaf).
Een van Die geskepte alliansie is 'n oplossing vir die probleem van die verspreiding van moderne modulêre toepassings met 'n groot aantal afhanklikhede. In sulke toepassings kan elke afhanklikheid 'n potensiële bron van kwesbaarhede of aanvalle wees. Deur beheer oor 'n afhanklikheid te neem, kan jy beheer kry oor alle toepassings wat daarmee geassosieer word. Vertroue in die toepassing impliseer outomaties vertroue in alle afhanklikhede, maar afhanklikhede word dikwels ontwikkel en onderhou deur derdeparty-spanne wie se aktiwiteite nie beheer kan word nie. Bytecode Alliance-lede beoog om 'n holistiese oplossing te verskaf vir veilige uitvoering van WebAssembly-toepassings wat nie inherent betroubaar is nie.
Vir beskerming word voorgestel om die konsep van nanoprosesse te gebruik, waarin elke afhanklikheidsmodule geskei word in 'n afsonderlik geïsoleerde WebAssembly-module, waarvan die magte slegs in verhouding tot hierdie module gestel word (byvoorbeeld, 'n biblioteek vir die verwerking van stringe sal nie in staat wees om 'n netwerksok of lêer oop te maak). Anders as prosesskeiding, is WebAssembly-hanteerders liggewig en benodig byna geen bykomende hulpbronne nie - interaksie tussen hanteerders is nie veel stadiger as om gewone funksies op te roep nie. Skeiding kan nie net op die vlak van individuele modules gedoen word nie, maar ook op die vlak van groepe modules wat byvoorbeeld met gemeenskaplike geheueareas moet werk
Die gevraagde magte kan beide op die vlak van die afhanklikhede self bepaal word, en deur ouermodules aan afhanklikhede langs die ketting gedelegeer word (hulpbronne in WASI word geassosieer met 'n spesiale tipe lêerbeskrywer - vermoë). Byvoorbeeld, 'n module kan die vermoë om toegang tot 'n spesifieke gids en stelseloproepe te verkry, gedelegeer word, en as die module se ontwikkelingsinfrastruktuur in die gedrang kom of 'n kwesbaarheid geïdentifiseer word, sal toegang slegs tot hierdie hulpbronne tydens 'n aanval beperk word. Hulpbronverklarings deur moduleskeppers kan 'n aanduiding wees van verdagte aktiwiteit, soos wanneer 'n teksverwerkingsmodule toestemming versoek om 'n netwerkverbinding oop te maak. Die aanvanklik gestelde toestemmings word nagegaan en as hulle verander, word die afhanklikheidslaai verwerp totdat die plaaslike module handtekening opgedateer is.
Vir gesamentlike ontwikkeling onder die vlerk van die Bytecode Alliance verskeie verwant aan WebAssembly , voorheen afsonderlik ontwikkel deur die alliansie se stigtersmaatskappye:
- - Looptyd om WebAssembly-toepassings met WASI-uitbreidings as gewone selfstandige toepassings te laat loop. Dit ondersteun beide die bekendstelling van WebAssembly-greepkode met behulp van 'n spesiale opdragreël-nutsding en die koppeling van klaargemaakte uitvoerbare lêers (wasmtime is in die toepassing ingebou as 'n biblioteek). Wasmtime het 'n buigsame modulêre struktuur wat jou toelaat om die looptyd vir verskeie toepassings te skaal, byvoorbeeld, jy kan 'n gestroopte weergawe vir toestelle met beperkte hulpbronne skep;
- - samesteller en looptyd vir die uitvoering van programme in WebAssembly-formaat. Kenmerkende Lucet is die gebruik van volledige antisiperende samestelling (AOT, voor die tyd) in plaas van JIT in masjienkode wat geskik is vir direkte uitvoering. Die projek is deur Fastly ontwikkel en is geoptimaliseer om minimale hulpbronne te verbruik en nuwe gevalle baie vinnig te begin (Fastly gebruik Lucet in 'n wolkrand rekenaarenjin wat WebAssembly gebruik vir hanteerders wat op elke versoek van stapel gestuur word). As deel van die gesamentlike projek word beplan om die Lucet-samesteller omskep te word om Wasmtime as 'n basis te gebruik;
- (WebAssembly Micro Runtime) is 'n ander looptyd vir die uitvoering van WebAssembly, wat oorspronklik deur Intel ontwikkel is vir gebruik in Internet of Things-toestelle. WAMR is geoptimaliseer vir minimale hulpbronverbruik en kan op toestelle met 'n klein hoeveelheid RAM gebruik word. Die projek sluit 'n tolk en virtuele masjien in vir die uitvoering van WebAssembly-greepkode, 'n API ('n subset van Libc) en gereedskap vir dinamiese toepassingsbestuur;
- - 'n kodegenerator wat 'n tussenvoorstelling onafhanklik van hardeware-argitekture vertaal in uitvoerbare masjienkode wat vir spesifieke hardewareplatforms geoptimaliseer is. Cranelift ondersteun parallelisering van funksiesamestelling vir baie vinnige resultaatgenerering, wat dit toelaat om gebruik te word om JIT-samestellers te skep (Cranelift-gebaseerde JIT word in die Wasmtime virtuele masjien gebruik);
- — 'n aparte implementering van die WASI (WebAssembly System Interface) API vir die organisering van interaksie met die bedryfstelsel;
- — 'n module vir die Cargo-pakketbestuurder wat 'n opdrag implementeer vir die samestelling van Rust-kode in WebAssembly-greepkode met behulp van die WASI-koppelvlak vir die gebruik van WebAssembly buite die blaaier;
- и — Ontleders vir die ontleding van teks (WAT, WAST) en binêre voorstellings van WebAssembly-greepkode.
Om saam te vat, WebAssembly is baie soos Asm.js, maar deurdat dit 'n binêre formaat is wat nie aan JavaScript gekoppel is nie en toelaat dat laevlak-intermediêre kode saamgestel uit verskeie programmeertale in die blaaier uitgevoer word. WebAssembly vereis nie 'n vullisverwyderaar nie, want dit gebruik eksplisiete geheuebestuur. Deur JIT vir WebAssembly te gebruik, kan jy prestasievlakke naby aan inheemse kode bereik. Een van die hoofdoelwitte van WebAssembly is om oordraagbaarheid, voorspelbare gedrag en identiese kode-uitvoering op verskillende platforms te verseker.
Bron: opennet.ru