Mozilla, Fastly, Intel e Red Hat promuovono WebAssembly come piattaforma di utilizzo universale

Mozilla, Fastly, Intel e Red Hat unito i suoi sforzi nello sviluppo di tecnologie che aiutano a rendere WebAssembly una piattaforma universale per l'esecuzione sicura del codice su qualsiasi infrastruttura, sistema operativo o dispositivo. Si è formata una comunità per lo sviluppo congiunto di runtime e compilatori che consentono l'utilizzo di WebAssembly non solo nei browser web Alleanza bytecode.

Per creare programmi portabili forniti in formato WebAssembly che possono essere eseguiti all'esterno del browser, suggeriamo di utilizzare l'API ERO IO (WebAssembly System Interface), che fornisce interfacce software per l'interazione diretta con il sistema operativo (API POSIX per lavorare con file, socket, ecc.). Una caratteristica distintiva del modello di esecuzione delle applicazioni che utilizzano WASI è che vengono eseguite in un ambiente sandbox per l'isolamento dal sistema principale e utilizzano un meccanismo di sicurezza basato sulla gestione delle capacità per le azioni con ciascuna delle risorse (file, directory, socket, chiamate di sistema , ecc.) all'applicazione devono essere fornite le autorizzazioni appropriate (viene fornito solo l'accesso alla funzionalità dichiarata).

Uno di obiettivi L'alleanza creata è una soluzione al problema della distribuzione di moderne applicazioni modulari con un gran numero di dipendenze. In tali applicazioni, ogni dipendenza può essere una potenziale fonte di vulnerabilità o attacchi. Assumere il controllo di una dipendenza consente di ottenere il controllo di tutte le applicazioni ad essa associate. La fiducia nell'applicazione implica automaticamente la fiducia in tutte le dipendenze, ma le dipendenze sono spesso sviluppate e gestite da team di terze parti le cui attività non possono essere controllate. I membri della Bytecode Alliance intendono fornire una soluzione olistica per l'esecuzione sicura di applicazioni WebAssembly che non sono intrinsecamente affidabili.

Per protezione, si propone di utilizzare il concetto di nanoprocessi, in cui ciascun modulo di dipendenza è separato in un modulo WebAssembly isolato separatamente, i cui poteri sono impostati in relazione solo a questo modulo (ad esempio, una libreria per l'elaborazione di stringhe non lo farà essere in grado di aprire un socket di rete o un file). A differenza della separazione dei processi, i gestori WebAssembly sono leggeri e non richiedono quasi risorse aggiuntive: l'interazione tra i gestori non è molto più lenta rispetto alla chiamata di funzioni ordinarie. La separazione può essere effettuata non solo a livello di singoli moduli, ma anche a livello di gruppi di moduli che, ad esempio, devono lavorare con aree di memoria comuni

I poteri richiesti possono essere determinati sia a livello delle dipendenze stesse, sia delegati alle dipendenze lungo la catena dai moduli principali (le risorse in WASI sono associate a un tipo speciale di descrittore di file - capacità). Ad esempio, a un modulo può essere delegata la possibilità di accedere a una directory specifica e a chiamate di sistema e, se l’infrastruttura di sviluppo del modulo viene compromessa o viene identificata una vulnerabilità, durante un attacco l’accesso sarà limitato solo a queste risorse. Le dichiarazioni delle risorse da parte dei creatori dei moduli possono essere un indicatore di attività sospette, ad esempio quando un modulo di elaborazione testo richiede l'autorizzazione per aprire una connessione di rete. Vengono verificati i permessi impostati inizialmente e, se cambiano, il caricamento delle dipendenze viene rifiutato fino all'aggiornamento della firma del modulo locale.

Per lo sviluppo congiunto sotto l'ala protettrice della Bytecode Alliance tradotto diversi relativi a WebAssembly progetti, precedentemente sviluppato separatamente dalle società fondatrici dell’alleanza:

  • Era tempo — runtime per l'esecuzione di applicazioni WebAssembly con estensioni WASI come normali applicazioni autonome. Supporta sia l'avvio del bytecode WebAssembly utilizzando una speciale utilità della riga di comando sia il collegamento di file eseguibili già pronti (wasmtime è integrato nell'applicazione come libreria). Wasmtime ha una struttura modulare flessibile che ti consente di scalare il runtime per varie applicazioni, ad esempio puoi creare una versione ridotta per dispositivi con risorse limitate;
  • Lucetto — compilatore e runtime per l'esecuzione di programmi in formato WebAssembly. Distintivo caratteristica Lucet è l'uso della compilazione anticipata completa (AOT, ahead-of-time) invece del JIT in un codice macchina adatto all'esecuzione diretta. Il progetto è stato sviluppato da Fastly ed è ottimizzato per consumare risorse minime e lanciare nuove istanze molto rapidamente (Fastly utilizza Lucet in un motore di cloud edge computing che utilizza WebAssembly per i gestori avviati su ogni richiesta). Nell'ambito del progetto comune è prevista la conversione del compilatore Lucet per utilizzare Wasmtime come base;
  • WAMR (WebAssembly Micro Runtime) è un altro runtime per l'esecuzione di WebAssembly, originariamente sviluppato da Intel per l'utilizzo nei dispositivi Internet of Things. WAMR è ottimizzato per un consumo minimo di risorse e può essere utilizzato su dispositivi con una piccola quantità di RAM. Il progetto include un interprete e una macchina virtuale per l'esecuzione del bytecode WebAssembly, un'API (un sottoinsieme di Libc) e strumenti per la gestione dinamica delle applicazioni;
  • gru — un generatore di codice che traduce una rappresentazione intermedia indipendente dalle architetture hardware in codice macchina eseguibile ottimizzato per piattaforme hardware specifiche. Cranelift supporta la parallelizzazione della compilazione di funzioni per la generazione di risultati molto rapida, che ne consente l'utilizzo per creare compilatori JIT (JIT basato su Cranelift viene utilizzato nella macchina virtuale Wasmtime);
  • WASI comune — un'implementazione separata dell'API WASI (WebAssembly System Interface) per organizzare l'interazione con il sistema operativo;
  • cargo-wasi — un modulo per il gestore pacchetti Cargo che implementa un comando per compilare il codice Rust nel bytecode WebAssembly utilizzando l'interfaccia WASI per utilizzare WebAssembly al di fuori del browser;
  • wat и wasmparser — parser per l'analisi del testo (WAT, WAST) e rappresentazioni binarie del bytecode WebAssembly.

Per ricapitolare, WebAssembly è molto simile ad Asm.js, ma diverso in quanto si tratta di un formato binario che non è legato a JavaScript e consente l'esecuzione nel browser di codice intermedio di basso livello compilato da vari linguaggi di programmazione. WebAssembly non richiede un Garbage Collector poiché utilizza la gestione esplicita della memoria. Utilizzando JIT per WebAssembly, puoi raggiungere livelli di prestazioni vicini al codice nativo. Tra gli obiettivi principali di WebAssembly c'è quello di garantire portabilità, comportamento prevedibile ed esecuzione identica del codice su piattaforme diverse.

Fonte: opennet.ru

Aggiungi un commento