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. afb Application Services AG, München
  2. über PT Personal Trust GmbH, Hamburg (Home-Office möglich)
  3. Eppendorf AG, Jülich
  4. Wirecard Technologies GmbH, Aschheim bei München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 204,90€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Google Game Builder ausprobiert: Spieldesign mit Karten statt Quellcode
Google Game Builder ausprobiert
Spieldesign mit Karten statt Quellcode

Bitte Bild wackeln lassen und dann eine Explosion: Solche Befehle als Reaktion auf Ereignisse lassen sich im Game Builder relativ einfach verketten. Der Spieleeditor des Google-Entwicklerteams Area 120 ist nicht nur für Einsteiger gedacht - sondern auch für Profis, etwa für die Erstellung von Prototypen.
Von Peter Steinlechner

  1. Spielebranche Immer weniger wollen Spiele in Deutschland entwickeln
  2. Aus dem Verlag Neue Herausforderungen für Spieler und Entwickler

Galaxy Note 10 im Hands on: Samsungs Stift-Smartphone kommt in zwei Größen
Galaxy Note 10 im Hands on
Samsungs Stift-Smartphone kommt in zwei Größen

Samsung hat sein neues Android-Smartphone Galaxy Note 10 präsentiert - erstmals in zwei Versionen: Die Plus-Variante hat ein größeres Display und einen größeren Akku sowie eine zusätzliche ToF-Kamera. Günstig sind sie nicht.
Ein Hands on von Tobias Költzsch

  1. Werbung Samsung bewirbt Galaxy Note 10 auf seinen Smartphones
  2. Smartphone Samsung präsentiert Kamerasensor mit 108 Megapixeln
  3. Galaxy Note 10 Samsung korrigiert Falschinformation zum Edelstahlgehäuse

Noise Cancelling Headphones 700 im Test: Boses bester ANC-Kopfhörer sticht Sony vielfach aus
Noise Cancelling Headphones 700 im Test
Boses bester ANC-Kopfhörer sticht Sony vielfach aus

Bose schafft mit seinen neuen Noise Cancelling Headphones 700 eine fast so gute Geräuschreduzierung wie Sony und ist in manchen Punkten sogar besser. Die Kopfhörer haben uns beim Testen aber auch mal genervt.
Ein Test von Ingo Pakalski

  1. Bose Frames im Test Sonnenbrille mit Musik
  2. Noise Cancelling Headphones 700 ANC-Kopfhörer von Bose versprechen tollen Klang
  3. Frames Boses Audio-Sonnenbrille kommt für 230 Euro nach Deutschland

  1. Verfassungsschutz: Einbruch für den Staatstrojaner
    Verfassungsschutz
    Einbruch für den Staatstrojaner

    Der Verfassungsschutz soll künftig auch Computer und Smartphones von Verdächtigen durchsuchen dürfen. Um Staatstrojaner zu installieren, sollen Wohnungseinbrüche erlaubt sein.

  2. Be emobil: Berliner Ladesäulen auf Verbrauchsabrechnung umgestellt
    Be emobil
    Berliner Ladesäulen auf Verbrauchsabrechnung umgestellt

    Der Ladenetzbetreiber Allego hat die Abrechnung der öffentlichen Ladestationen in Berlin umgestellt. Statt eines Pauschalpreises für den Ladevorgang zahlen Elektroautomobilisten in Zukunft nach geladener Strommenge.

  3. Segway-Ninebot: E-Scooter sollen autonom zur Ladestation fahren
    Segway-Ninebot
    E-Scooter sollen autonom zur Ladestation fahren

    Das Aufladen von E-Scootern ist für die Verleihdienste aufwendig und kostspielig. Daher könnten künftig Geister-Scooter durch die Städte rollen. Beim Kauf "normaler" E-Scooter gibt es derweil Verzögerungen.


  1. 14:28

  2. 13:20

  3. 12:29

  4. 11:36

  5. 09:15

  6. 17:43

  7. 16:16

  8. 15:55