Abo
  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. Zum Login

Stellenmarkt
  1. ADAC Luftrettung gGmbH, München
  2. via 3C - Career Consulting Company GmbH, Frankfurt
  3. Hornbach-Baumarkt-AG, Bornheim (Pfalz)
  4. Stadtwerke München GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 39,99€ (Release am 3. Dezember)
  2. 4,99€
  3. 0,49€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Funkstandards: Womit funkt das smarte Heim?
Funkstandards
Womit funkt das smarte Heim?

Ob Wohnung oder Haus: Smart soll es bitte sein. Und wenn das nicht von Anfang an klappt, soll die Nachrüstung zum Smart Home so wenig aufwendig wie möglich sein. Dafür kommen vor allem Funklösungen infrage, wir stellen die gebräuchlichsten vor.
Von Jan Rähm

  1. Local Home SDK Google bietet SDK für Smarthomesteuerung im lokalen Netzwerk
  2. GE Smarte Lampe mit 11- bis 13-stufigem Resetverfahren
  3. IoT Smart Homes ohne Internet, geht das? Ja!

IT-Sicherheit: Auch kleine Netze brauchen eine Firewall
IT-Sicherheit
Auch kleine Netze brauchen eine Firewall

Unternehmen mit kleinem Geldbeutel verzichten häufig auf eine Firewall. Das sollten sie aber nicht tun, wenn ihnen die Sicherheit ihres Netzwerks wichtig ist.
Von Götz Güttich

  1. Anzeige Wo Daten wirklich sicher liegen
  2. Erasure Coding Das Ende von Raid kommt durch Mathematik
  3. Endpoint Security IT-Sicherheit ist ein Cocktail mit vielen Zutaten

Change-Management: Die Zeiten, sie, äh, ändern sich
Change-Management
Die Zeiten, sie, äh, ändern sich

Einen Change zu wollen, gehört heute zum guten Ton in der Unternehmensführung. Doch ein erzwungener Wandel in der Firmenkultur löst oft keine Probleme und schafft sogar neue.
Ein Erfahrungsbericht von Marvin Engel

  1. Recruiting Alle Einstellungsprozesse sind fehlerhaft
  2. LoL Was ein E-Sport-Trainer können muss
  3. IT-Arbeit Was fürs Auge

  1. Radikalisierung: Die meisten Menschen leben nicht in einer Blase
    Radikalisierung
    Die meisten Menschen leben nicht in einer Blase

    Dass fast jeder in gefährlichen Filterblasen oder Echokammern lebt, ist ein Mythos, sagt die Kommunikationswissenschaftlerin Merja Mahrt. Radikalisierung findet nicht nur im Internet statt, doch darauf wird meist geschaut.

  2. Mozilla: Firefox 70 zeigt Übersicht zu Tracking-Schutz
    Mozilla
    Firefox 70 zeigt Übersicht zu Tracking-Schutz

    Der Tracking-Schutz des Firefox blockiert sehr viele Elemente, die in der aktuellen Version 70 des Browsers für die Nutzer ausgewertet werden. Der Passwortmanager Lockwise ist nun Teil des Browsers und die Schloss-Symbole für HTTPS werden verändert.

  3. Softbank: Wework fällt von 47 auf 8 Milliarden US-Dollar
    Softbank
    Wework fällt von 47 auf 8 Milliarden US-Dollar

    In einer neuen Vereinbarung erlangt die japanische Softbank die Kontrolle über das Co-Working-Startup Wework. Es fällt dabei erheblich im Wert und entgeht dem drohenden Bankrott.


  1. 19:37

  2. 16:42

  3. 16:00

  4. 15:01

  5. 14:55

  6. 14:53

  7. 14:30

  8. 13:35