Mozilla, Fastly, Intel und Red Hat fördern WebAssembly als universell einsetzbare Plattform

Mozilla, Fastly, Intel und Red Hat vereinigt seine Bemühungen bei der Entwicklung von Technologien, die dazu beitragen, WebAssembly zu einer universellen Plattform für die sichere Codeausführung über jede Infrastruktur, jedes Betriebssystem oder jedes Gerät hinweg zu machen. Zur gemeinsamen Entwicklung von Laufzeit- und Compilern hat sich eine Community gebildet, die den Einsatz von WebAssembly nicht nur in Webbrowsern ermöglicht Bytecode-Allianz.

Um portable Programme im WebAssembly-Format zu erstellen, die außerhalb des Browsers ausgeführt werden können, empfehlen wir die Verwendung der API WAR ICH (WebAssembly System Interface), das Softwareschnittstellen für die direkte Interaktion mit dem Betriebssystem bereitstellt (POSIX-API für die Arbeit mit Dateien, Sockets usw.). Ein besonderes Merkmal des Ausführungsmodells von Anwendungen, die WASI verwenden, besteht darin, dass sie in einer Sandbox-Umgebung zur Isolierung vom Hauptsystem ausgeführt werden und einen Sicherheitsmechanismus verwenden, der auf der Fähigkeitsverwaltung für Aktionen mit jeder der Ressourcen (Dateien, Verzeichnisse, Sockets, Systemaufrufe) basiert usw.) müssen der Anwendung die entsprechenden Berechtigungen erteilt werden (es wird nur Zugriff auf die deklarierte Funktionalität gewährt).

Einer von Ziele Die geschaffene Allianz ist eine Lösung für das Problem der Verteilung moderner modularer Anwendungen mit vielen Abhängigkeiten. In solchen Anwendungen kann jede Abhängigkeit eine potenzielle Quelle für Schwachstellen oder Angriffe sein. Wenn Sie die Kontrolle über eine Abhängigkeit übernehmen, können Sie die Kontrolle über alle damit verbundenen Anwendungen erlangen. Vertrauen in die Anwendung impliziert automatisch Vertrauen in alle Abhängigkeiten. Abhängigkeiten werden jedoch häufig von Drittteams entwickelt und verwaltet, deren Aktivitäten nicht kontrolliert werden können. Die Mitglieder der Bytecode Alliance beabsichtigen, eine ganzheitliche Lösung für die sichere Ausführung von WebAssembly-Anwendungen bereitzustellen, die nicht von Natur aus vertrauenswürdig sind.

Zum Schutz wird vorgeschlagen, das Konzept der Nanoprozesse zu verwenden, bei dem jedes Abhängigkeitsmodul in ein separat isoliertes WebAssembly-Modul unterteilt wird, dessen Befugnisse nur in Bezug auf dieses Modul festgelegt werden (z. B. eine Bibliothek zur Verarbeitung von Zeichenfolgen nicht). in der Lage sein, einen Netzwerk-Socket oder eine Datei zu öffnen). Im Gegensatz zur Prozesstrennung sind WebAssembly-Handler leichtgewichtig und erfordern fast keine zusätzlichen Ressourcen – die Interaktion zwischen Handlern ist nicht viel langsamer als der Aufruf gewöhnlicher Funktionen. Die Trennung kann nicht nur auf der Ebene einzelner Module erfolgen, sondern auch auf der Ebene von Modulgruppen, die beispielsweise mit gemeinsamen Speicherbereichen arbeiten müssen

Die angeforderten Befugnisse können sowohl auf der Ebene der Abhängigkeiten selbst bestimmt als auch von übergeordneten Modulen an Abhängigkeiten entlang der Kette delegiert werden (Ressourcen in WASI sind einem speziellen Typ von Dateideskriptor zugeordnet – der Fähigkeit). Beispielsweise kann einem Modul die Möglichkeit delegiert werden, auf ein bestimmtes Verzeichnis und Systemaufrufe zuzugreifen. Wenn die Entwicklungsinfrastruktur des Moduls gefährdet ist oder eine Schwachstelle festgestellt wird, ist der Zugriff während eines Angriffs nur auf diese Ressourcen beschränkt. Ressourcendeklarationen durch Modulersteller können ein Indikator für verdächtige Aktivitäten sein, beispielsweise wenn ein Textverarbeitungsmodul die Erlaubnis zum Öffnen einer Netzwerkverbindung anfordert. Die anfänglich festgelegten Berechtigungen werden überprüft und bei einer Änderung wird das Laden der Abhängigkeit abgelehnt, bis die lokale Modulsignatur aktualisiert wird.

Für die gemeinsame Entwicklung unter der Schirmherrschaft der Bytecode Alliance übersetzt mehrere im Zusammenhang mit WebAssembly projekte, zuvor separat von den Gründungsunternehmen der Allianz entwickelt:

• wasmtime – Laufzeit zum Ausführen von WebAssembly-Anwendungen mit WASI-Erweiterungen als reguläre eigenständige Anwendungen. Es unterstützt sowohl das Starten von WebAssembly-Bytecode mithilfe eines speziellen Befehlszeilenprogramms als auch das Verknüpfen vorgefertigter ausführbarer Dateien (wasmtime ist als Bibliothek in die Anwendung integriert). Wasmtime verfügt über eine flexible modulare Struktur, die es Ihnen ermöglicht, die Laufzeit für verschiedene Anwendungen zu skalieren. Sie können beispielsweise eine abgespeckte Version für Geräte mit begrenzten Ressourcen erstellen;
• Lucet – Compiler und Laufzeit zum Ausführen von Programmen im WebAssembly-Format. Unverwechselbar Feature Lucet ist die Verwendung einer vollwertigen vorausschauenden Kompilierung (AOT, Ahead-of-Time) anstelle von JIT in Maschinencode, der für die direkte Ausführung geeignet ist. Das Projekt wurde von Fastly entwickelt und ist darauf optimiert, nur minimale Ressourcen zu verbrauchen und neue Instanzen sehr schnell zu starten (Fastly verwendet Lucet in einer Cloud-Edge-Computing-Engine, die WebAssembly für Handler verwendet, die bei jeder Anfrage gestartet werden). Im Rahmen des Gemeinschaftsprojekts ist die Umstellung des Lucet-Compilers auf die Nutzung von Wasmtime als Basis geplant;
• WAMR (WebAssembly Micro Runtime) ist eine weitere Laufzeit zur Ausführung von WebAssembly, die ursprünglich von Intel für den Einsatz in Internet-of-Things-Geräten entwickelt wurde. WAMR ist für minimalen Ressourcenverbrauch optimiert und kann auf Geräten mit wenig RAM verwendet werden. Das Projekt umfasst einen Interpreter und eine virtuelle Maschine zum Ausführen von WebAssembly-Bytecode, eine API (eine Teilmenge von Libc) und Tools für die dynamische Anwendungsverwaltung;
• Kranlift – ein Codegenerator, der eine von Hardwarearchitekturen unabhängige Zwischendarstellung in ausführbaren Maschinencode übersetzt, der für bestimmte Hardwareplattformen optimiert ist. Cranelift unterstützt die Parallelisierung der Funktionskompilierung für eine sehr schnelle Ergebnisgenerierung, wodurch es zur Erstellung von JIT-Compilern verwendet werden kann (Cranelift-basiertes JIT wird in der virtuellen Wasmtime-Maschine verwendet);
• WASI üblich — eine separate Implementierung der WASI-API (WebAssembly System Interface) zur Organisation der Interaktion mit dem Betriebssystem;
• Fracht-Wasi – ein Modul für den Cargo-Paketmanager, das einen Befehl zum Kompilieren von Rust-Code in WebAssembly-Bytecode mithilfe der WASI-Schnittstelle implementiert, um WebAssembly außerhalb des Browsers zu verwenden;
• Was и Wasmparser – Parser zum Parsen von Text (WAT, WAST) und binären Darstellungen von WebAssembly-Bytecode.

Um es noch einmal zusammenzufassen: WebAssembly ist Asm.js sehr ähnlich, aber anders , dass es sich um ein Binärformat handelt, das nicht an JavaScript gebunden ist und die Ausführung von Low-Level-Zwischencode, der aus verschiedenen Programmiersprachen kompiliert wurde, im Browser ermöglicht. WebAssembly erfordert keinen Garbage Collector, da es eine explizite Speicherverwaltung verwendet. Durch die Verwendung von JIT für WebAssembly können Sie Leistungsniveaus erreichen, die denen von nativem Code nahe kommen. Zu den Hauptzielen von WebAssembly gehört die Gewährleistung von Portabilität, vorhersehbarem Verhalten und identischer Codeausführung auf verschiedenen Plattformen.

Source: opennet.ru