1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Wasmjit: Webassembly-Laufzeit…

Ein Paradies für Spitzbuben?

  1. Thema

Neues Thema Ansicht wechseln


  1. Ein Paradies für Spitzbuben?

    Autor: M.P. 27.09.18 - 10:09

    > Das Webassembly-Projekt (Wasm) soll eigentlich einen einheitlichen Bytecode für das Web erstellen, der dann schnell und sicher in Browsern ausgeführt werden kann. Das Projekt Wasmjit will die Nutzung von Webassembly allerdings aus dem Browser herausholen und im Ring O, also im Kernel, umsetzen.

    Oder verstehe ich den Sinn des Ganzen nicht, und dieses Vorhaben untergräbt die Sicherheit eines Linux Systems nicht?

  2. Re: Ein Paradies für Spitzbuben?

    Autor: gunterkoenigsmann 27.09.18 - 11:33

    Das war auch meine Idee: Statt Sandboxing werden die Sachen jetzt ins Kernel verschoben? Irgendwie fehlt mir da ein Puzzlesteinchen. Oder wollen wir jetzt Kerneltreiber in Web Assembly schreiben?

  3. Re: Ein Paradies für Spitzbuben?

    Autor: ashahaghdsa 27.09.18 - 12:05

    Der Webassembly Bytecode kann nur in ihm einem ihn zugewiesenem Speicherbereich arbeiten und nur über Fehler in der Runtime daraus ausbrechen. Wenn ich jetzt nen Treiber in Webassembly schreibe, dann bringt das erstmal mehr Sicherheit. Den Code direkt im Kernel auszuführen bringt Performance, dafür den Nachteil, dass Fehler in der Runtime direkt Kernel Rechte statt User Rechte bringen.
    Ich denke nicht, dass mittelfristig der Browser ungeprüfte Webassembly im Kernel ausführen wird. Mir wäre aber viel wohler, wenn Firmen ihre Binärtreiber als Webassembly veröffentlichen statt als binär .ko. Oder auch der NTFS treiber, verarbeitet haufenweise fremde, potentiell gefährliche Hardware, der kann extra Sicherheit gerne gebrauchen, Performance sowieso.

    Ob das am Ende des Tages tatsächlich mehr Performance bringt, muss sich natürlich noch zeigen.

  4. Re: Ein Paradies für Spitzbuben?

    Autor: qwertü 27.09.18 - 14:23

    Nein, es untergräbt die Sicherheit nicht. Was man über die Separierung von Kernel und Userspace-Programmen, bzw. Userspace-Programmen untereinander erreichen will, ist, dass jedes Programm nur auf seine eigenen Daten (im RAM) zugreifen kann.

    Normalerweise funktioniert das über virtuellen Speicher, d.h. jedes Programm sieht einen Adressbereich, der bei 0 beginnt, und die Hardware hat irgendwo ein Mapping, wo welcher Speicherbereich welches Programms tatsächlich liegt.

    Das funktioniert auch prima und ist schnell, es sei denn, das Programm macht einen Syscall, und das kommt halt sehr häufig vor (Dateien/Netzwerk lesen/schreiben, etc). Da muss dann der komplette CPU-Zustand auf den Stack (des Programms) gelegt werden, das System wechselt in Ring 0, der Kernel arbeitet den Syscall ab, und dann wird der CPU-Zustand wieder geladen, das System geht wieder aus Ring 0 raus und das Programm arbeitet weiter. Dieser Kontextwechsel ist ein krasser Performance-Overhead, aber halt aus Sicherheitsgründen notwendig.

    Schneller wäre es, wenn das Programm für den Syscall nur einen Funktionsaufruf bräuchte, aber das geht ja nicht, weil der Syscall den Adressbereich des Kernels nutzt (Ring 0), und der Code nicht im Userspace laufen kann. Die andere Möglichkeit wäre, das Programm halt auch in Ring 0 laufen zu lassen, aber dann muss man dem Binary vertrauen, dass es mit dem Rest des Kernel-Adressbereichs keinen Scheiß anstellt, was schwierig ist, denn Programme haben eben Bugs.

    Webassembly löst dieses Sicherheitsproblem, indem es den Webassembly-Code zu nativem Code JIT-kompiliert, und dabei Checks mit einkompiliert, welche die Speicherzugriffe zur Laufzeit überprüfen. Das ist zwar auch ein Overhead, aber der ist geringer. Jetzt kann man den Code guten Gewissens in Ring 0 laufen lassen, und ein Syscall ist nur noch ein Funktionsaufruf, d.h. den Kontextwechesel-Overhead spart man sich.

    Der relevante Teil eines sehr guten Talks (den man sich am besten komplett anschaut), ist bei 14:14 in https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript (hat stiGGG in nem anderen Thread schon verlinkt)

  5. Re: Ein Paradies für Spitzbuben?

    Autor: qbl 27.09.18 - 16:51

    qwertü schrieb:
    --------------------------------------------------------------------------------
    > Nein, es untergräbt die Sicherheit nicht.
    Was zu beweisen wäre...
    > Was man über die Separierung von
    > Kernel und Userspace-Programmen, bzw. Userspace-Programmen untereinander
    > erreichen will, ist, dass jedes Programm nur auf seine eigenen Daten (im
    > RAM) zugreifen kann.
    >
    > Normalerweise funktioniert das über virtuellen Speicher, d.h. jedes
    > Programm sieht einen Adressbereich, der bei 0 beginnt, und die Hardware hat
    > irgendwo ein Mapping, wo welcher Speicherbereich welches Programms
    > tatsächlich liegt.
    >
    > Das funktioniert auch prima und ist schnell, es sei denn, das Programm
    > macht einen Syscall, und das kommt halt sehr häufig vor (Dateien/Netzwerk
    > lesen/schreiben, etc). Da muss dann der komplette CPU-Zustand auf den Stack
    > (des Programms) gelegt werden, das System wechselt in Ring 0, der Kernel
    > arbeitet den Syscall ab, und dann wird der CPU-Zustand wieder geladen, das
    > System geht wieder aus Ring 0 raus und das Programm arbeitet weiter. Dieser
    > Kontextwechsel ist ein krasser Performance-Overhead, aber halt aus
    > Sicherheitsgründen notwendig.
    Korrekt. Allerdings ist selbst eine SSD nicht so schnell, dass sie einen modernen Prozessor ausbremsen könnte. Was langsamer läuft ist das Programm, welches auf die Daten wartet. Der Performanzgewinn ist dem gegenüber vernachlässigbar. Anders sieht es bei Grafik- oder Soundkarte aus. Dort verwendet man genau deshalb eigene Prozessoren...
    >
    > Schneller wäre es, wenn das Programm für den Syscall nur einen
    > Funktionsaufruf bräuchte, aber das geht ja nicht, weil der Syscall den
    > Adressbereich des Kernels nutzt (Ring 0), und der Code nicht im Userspace
    > laufen kann. Die andere Möglichkeit wäre, das Programm halt auch in Ring 0
    > laufen zu lassen, aber dann muss man dem Binary vertrauen, dass es mit dem
    > Rest des Kernel-Adressbereichs keinen Scheiß anstellt, was schwierig ist,
    > denn Programme haben eben Bugs.
    Korrekt. Deshalb lesen oder schreiben vernünftige Programmierer die Daten nicht byteweise, sondern in möglichst großen Blöcken. Das verringert die Anzahl der Kontextswitches erheblich. Allerdings macht sich der resultierende Performanzgewinn nur auf genau dem Programm bemerkbar, das gerade Daten liest oder schreibt. Auf dem restlichen System bemerkt man das nur unter Vollast.
    >
    > Webassembly löst dieses Sicherheitsproblem, indem es den Webassembly-Code
    > zu nativem Code JIT-kompiliert, und dabei Checks mit einkompiliert, welche
    > die Speicherzugriffe zur Laufzeit überprüfen.
    Der zeitliche Overhead eines JIT-Compilers kann nur versteckt werden, wenn der übersetzte Code viele Schleifenkonstrukte enthält. Dann kann der JIT-Compiler parallel bereits „vorarbeiten“, was auf einer Mehrkerncpu nur dann auffällt, wenn das System unter Vollast läuft. Dann fehlt die benötigte Rechenzeit aber anderen Programmen...
    > Das ist zwar auch ein
    > Overhead, aber der ist geringer.
    Das ist eine bloße Vermutung und durch nichts belegt...
    > Jetzt kann man den Code guten Gewissens in
    > Ring 0 laufen lassen,
    Dort kann man „mit gutem Gewissen“ nur fehlerfreien Code laufen lassen, was zu beweisen wäre.
    > und ein Syscall ist nur noch ein Funktionsaufruf,
    > d.h. den Kontextwechesel-Overhead spart man sich.
    Der Kontextwechseloverhead macht sich nur bei Zugriff auf sehr schnelle Peripherie bemerkbar. Das ein Werbetexter dazu neigt die gängige Praxis, die Anzahl der Kontextwechsel durch Zusammenfassung zu vermeiden, nicht zu erwähnen, demgegenüber aber die permanente Mehrbelastung durch einen im günstigsten Falle parallel laufenden JIT-Compiler klein zu reden, ist die dort übliche Vorgehensweise, gehört aber meiner Meinung nach nicht in ein technisches Forum, sondern auf ein Prospekt...
    >
    > Der relevante Teil eines sehr guten Talks (den man sich am besten komplett
    > anschaut), ist bei 14:14 in www.destroyallsoftware.com (hat stiGGG in nem
    > anderen Thread schon verlinkt)


    Gruß
    qbl

  6. Re: Ein Paradies für Spitzbuben?

    Autor: zilti 28.09.18 - 10:04

    ashahaghdsa schrieb:
    --------------------------------------------------------------------------------
    > Wenn ich jetzt nen Treiber in Webassembly schreibe

    Welch Irrer tut sowas?

  7. Re: Ein Paradies für Spitzbuben?

    Autor: gunterkoenigsmann 28.09.18 - 11:01

    Wenn wir Treiber in WebAssembly schreiben, um Kontextwechsel zu vermeiden, die langsam geworden sind, unter anderem, weil wir Meltdown etc. verhindern wollen...
    ...dann bin ich gespannt, ob man dabei nicht doch was übersehen hat.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Android-Entwickler (m/w/d) Infotainment
    e.solutions GmbH, Erlangen
  2. IT-Netzwerkadministrator*in
    Fraunhofer-Institut für Optronik, Systemtechnik und Bildauswertung IOSB, Karlsruhe, Ettlingen
  3. IT Solutions Expert SAP (m/w/d)
    DLR Gesellschaft für Raumfahrtanwendungen (GfR) mbH, Oberpfaffenhofen
  4. SPS-Programmierer / Automatisierungstechniker (m/w/d)
    SR-Schindler Maschinen-Anlagentechnik GmbH, Regensburg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Biomutant für 33,49€, Frostpunk für 6,49€, Uno für 4,99€, Police Simulator: Patrol...
  2. 899€
  3. mit 150,90€ neuer Bestpreis auf Geizhals


Haben wir etwas übersehen?

E-Mail an news@golem.de


  1. Elon Musk: Tesla Model S bekommt ausschließlich Knight-Rider-Lenkrad
    Elon Musk
    Tesla Model S bekommt ausschließlich Knight-Rider-Lenkrad

    Elon Musk hat klargestellt, dass es für das Model S und das Model X kein normales Lenkrad mehr geben wird. Das D-förmige Lenkrad ist Pflicht.

  2. Förderprogramm: Bund will Fachkräfte für Akkuindustrie ausbilden lassen
    Förderprogramm
    Bund will Fachkräfte für Akkuindustrie ausbilden lassen

    Die Aus- und Weiterbildung für Fachleute im Bereich Akkuproduktion und -entwicklung wird mit 40 Millionen Euro aus der Staatskasse gefördert.

  3. Elektroauto: Mercedes EQS mit besserer Hinterachslenkung als Abo
    Elektroauto
    Mercedes EQS mit besserer Hinterachslenkung als Abo

    Den Mercedes EQS gibt es mit Hinterachslenkung mit 4,5 Grad Einschlag. Wer ein Jahresabo abschließt, bekommt sogar 10 Prozent Lenkeinschlag und damit eine bessere Lenkung.


  1. 16:00

  2. 15:00

  3. 14:15

  4. 13:21

  5. 12:30

  6. 11:20

  7. 11:05

  8. 10:51