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

Uhm

  1. Thema

Neues Thema Ansicht wechseln


  1. Uhm

    Autor: rener 27.09.18 - 10:09

    Ehrlich gesagt erschließt sich mir der Sinn nicht wirklich. Und Sicherheitstechnisch klingt das auf dem ersten Blick auch nach einem Alptraum.

  2. Re: Uhm

    Autor: Noren 27.09.18 - 10:35

    Vielleicht gibts ja Bedarf, Webassembly als neue stan­dar­di­sie­rten Zwischensprache auch ausserhalb von Browsern zu nutzen und eventuell kann das ja Vorteile beim Schreiben von Kernel Module bieten (nutzen muss ich diese Module ja nicht), aber wenn ich irgendwann einen Webserver im Ring 0 finde, kriege ich unkontrolierte Wutausbrüche.



    2 mal bearbeitet, zuletzt am 27.09.18 10:36 durch Noren.

  3. Re: Uhm

    Autor: Aluz 27.09.18 - 11:02

    Ja war auch mein Gedanke, das klang fuer mich so absurd wie "Adobe Flash in Ring 0"

    Ich finde es sehr gruselig. Selbst als nur ein Modul ist es gruselig. Was fuer ein Bollwerk muss das sein, dass man da unter keinen Umstaenden irgendwie was einschleusen kann...

    Und geht es nur mir so oder sind diese Gruselmeldungen im Bezug auf den Kernel auf einen Schlag nachdem Linus seine Auszeit angekuendigt hat mehr geworden? Als ob alle die, die von ihm abgeschmettert wurden nun ploetzlich angekrochen kommen da sie eine Chance sehen. Kann auch sein, dass ich das nur subjektiv so empfinde...

  4. Re: Uhm

    Autor: AnAmigian 27.09.18 - 11:06

    Nur für einen Monat, dann ist Gott zurück und wird, falls nötig die Ketzer zerschmettern. ;-D

  5. Re: Uhm

    Autor: teleborian 27.09.18 - 11:17

    In dem falle ganz gut, dass er eine Auszeit nimmt. Da kann man gleich mal den ernstfall testen wenn er. z.B. tatsächlich mal in Rente geht.

    Ich sehe viel Reorganisation auf die Kernel Entwickler zu kommen und je früher sie da beginnen desto besser und kontrollierbarer.

  6. Re: Uhm

    Autor: patrik.stutz 27.09.18 - 11:22

    WebAssembly als Sprache bietet offenbar keinerlei Möglichkeit auf stellen ausserhalb des eigenen Speicherbereichs zuzugreifen, was bedeuted dass es (solange es korrekt ausgeführt wird) keinerlei Sicherheitsrisiko darstellt.

    Ich weiss nicht ob das genau die Anforderung war, als man WebAssembly entwickelt hat, aber diese Eigenschaft haben anscheinend auch schon andere als nützlich erkannt und eröffnet völlig neue Möglichkeiten um Code sicher im Ring 0 auszuführen.

    Zum Beispiel wird mit Nebulet ein Micro-Kernel entwickelt, der nur WASM-Code ausführen kann, dafür aber komplett im Ring 0:

    https://www.phoronix.com/scan.php?page=news_item&px=Nebulet-Ring-0-WebAssembly
    https://github.com/nebulet/nebulet

    Der Vorteil davon ist, dass schon per Software verhindert wird, dass Programme ihren Speicherbereich verlassen und somit die CPU diese Aufgabe gar nicht mehr übernehmen muss. Das vereinfacht das CPU design und verhindert auch CPU bugs wie Meltdown & Spectre, bzw könnten solche fehler in zukunft per software ohne performanceeinbussen gepatcht werden.

  7. Re: Uhm

    Autor: tsx-11 27.09.18 - 11:32

    patrik.stutz schrieb:
    --------------------------------------------------------------------------------
    > WebAssembly als Sprache bietet offenbar keinerlei Möglichkeit auf stellen
    > ausserhalb des eigenen Speicherbereichs zuzugreifen, was bedeuted dass es
    > (solange es korrekt ausgeführt wird) keinerlei Sicherheitsrisiko
    > darstellt.
    [...]
    > Der Vorteil davon ist, dass schon per Software verhindert wird, dass
    > Programme ihren Speicherbereich verlassen und somit die CPU diese Aufgabe
    > gar nicht mehr übernehmen muss.

    Ist doch bei Java auch der Fall. Daher ist Java auch sicher.

  8. Re: Uhm

    Autor: patrik.stutz 27.09.18 - 11:39

    Ja, aber der Unterschied liegt darin, dass Java eine Laufzeitumgebung braucht (weil Garbage Collector etc.) und WASM direkt vor der ausführung zu nativem code kompiliert werden kann. Und runtimes sind natürlich ein Angriffsvektor, ganz speziell bei so komplexen wie der JVM. Ich würde sagen alle Garbage Collected sprachen scheiden nur schon deshalb aus (und natürlich auch als performance gründen)

    Rust z.B. würde wieder gehen, aber eben nur die Programmiersprache, kompillierte Rust-programme sind wieder unsicher. Wenn der Micro-Kernel Rust-Code direkt akzeptieren würde um diesen dann selbst vor der ausführung zu kompilieren, ginge das auch (sofern der code keine einzige unsafe aufweist).

    Um es vielleicht vereinfacht zu sagen: Mit WASM wurde eine Sprache gesucht und gefunden die es erlaubt code mit maximaler pferformance und absolut sicher im Browser auszuführen. Dann hat man wohl gemerkt, dass wenn es sicher ist es im Browser auszuführen, es auch sicher ist es gleich im Ring 0 auszuführen, da ein ausbrechen ja eigentlich unmöglich ist.



    3 mal bearbeitet, zuletzt am 27.09.18 11:54 durch patrik.stutz.

  9. Re: Uhm

    Autor: stiGGG 27.09.18 - 11:43

    Aluz schrieb:
    --------------------------------------------------------------------------------
    > Und geht es nur mir so oder sind diese Gruselmeldungen im Bezug auf den
    > Kernel auf einen Schlag nachdem Linus seine Auszeit angekuendigt hat mehr
    > geworden? Als ob alle die, die von ihm abgeschmettert wurden nun ploetzlich
    > angekrochen kommen da sie eine Chance sehen. Kann auch sein, dass ich das
    > nur subjektiv so empfinde...

    Linus kann (bzw konnte) nur „abschmettern“ was zur Aufnahme in den Hauptentwicklungszweig vorgeschlagen wurde. Davon steht bei diesem in der Tat seltsamen Modul nichts im Artikel. Um jedes Kernel Modul / Patch zu bewerten welch irgendjemand auf GitHub schmeißt, hat der Tag für ihn nicht genug Stunden. Das hat ihn auch nie gejuckt bzw er hat immer dazu aufgefordert, dass jeder sich seine eigene Version von Linux basteln soll und man sich dabei nicht drum kümmern soll was er dazu denkt.

  10. Re: Uhm

    Autor: Noren 27.09.18 - 12:23

    Ok, ich verstehe. Ist also die Umgebung, der Kompiler/der Interpreter fehlerlos, wäre es nicht möglich auf Speicher ausserhalb der Kontrolle des WASM Modules zuzugreifen. Allerdings sehe ich immer noch Sicherheitsprobleme bei jeglichen Schnittstellen. Nehmen wir an, WASM hätte eine Schnittstelle/Call/Syscall oder was auch immer um mit einem FileSystem zu interagieren (was z.B. bei Webservern üblich ist), so müsste zwangsweise WASM oder der Webserver oder selber Sicherheitsmechanismen enthalten damit dieser nur auf einen bestimmten vorgesehenen Teil zugreifen kann. Bestehende Berechtigungssysteme greifen nicht, da Ring 0.
    Somit besteht immer noch eine Gefahr, dass eine etwas komplexere Software viel mehr Schaden anrichten kann, als wenn sie in einem geschützten Bereich läuft.

  11. Re: Uhm

    Autor: patrik.stutz 27.09.18 - 12:56

    Ich glaube nicht, dass sich am restlichen Berechtigungssystem gross was ändern oder dies gefährlicher würde.

    Jetzt kann auch schon jedes Programm syscalls absetzen und es ist dann sache des syscalls zu prüfen ob der caller (also das programm) überhaupt über die nötigen rechte dafür verfügt. Daran würde sich ja nichts ändern.

    Wenn wir bei der heutigen architektur ein programm im ring 0 ausführen würden, hätte dieses auch nicht die berechtigung jeglichen syscall auszuführen. Aber da es zugriff auf den kompletten memory hat, kann es den syscall auch einfach umgehen.

    Im falle von Wasmjit wird eine syscall schnittschtelle ja auch explizit gar nicht angeboten, sondern das programm hat nur zugriff auf die üblichen web apis.

    Ich denke es ist sogar ein Sicherheitsgewinn, weil man nun z.B. treibern nur auf die für sie relevante hardware zugriff gewähren kann und diese nicht vollzugriff auf das system haben. Man müsste dann aber natürlich entsprechend neue Hardware-Zugriffs APIs definieren.



    2 mal bearbeitet, zuletzt am 27.09.18 13:12 durch patrik.stutz.

  12. Re: Uhm

    Autor: tsx-11 27.09.18 - 13:49

    patrik.stutz schrieb:
    --------------------------------------------------------------------------------
    > Im falle von Wasmjit wird eine syscall schnittschtelle ja auch explizit gar
    > nicht angeboten, sondern das programm hat nur zugriff auf die üblichen web
    > apis.

    ??? Wasmjit im Kernel hat doch Zugriff auf die Syscalls. I glaub ich muss mir das mal installieren. Ist bestimmt ein Spaß. Was passiert mit fork(), mmap(), ...

    > Ich denke es ist sogar ein Sicherheitsgewinn, weil man nun z.B. treibern
    > nur auf die für sie relevante hardware zugriff gewähren kann und diese
    > nicht vollzugriff auf das system haben. Man müsste dann aber natürlich
    > entsprechend neue Hardware-Zugriffs APIs definieren.

    Ja, kann man heute schon machen, in dem man die Treiber im Userspace laufen lässt.

    I glaube nicht das dieses Webassembly in Kernel die Lösung ist.

  13. Re: Uhm

    Autor: patrik.stutz 27.09.18 - 14:11

    Wasmjit selbst hat zugriff, ja. Der code, der darin ausgeführt wird aber natürlich nicht. Sonst könnte ja jede x-beliebige Website bei mir syscalls ausführen.

    Ja, aber userspace treiber sind langsamer, wegen den Contextswitches. Treiber sollten aber möglichst performant sein.

    Ich glaube Webassembly wird die Art und Weise wie Betriebssysteme aufgebaut sind komplett revolutionieren. Allerdings wird das noch ein paar Jahrzehnte dauern.

    Eigentlich bin ich sogar überrascht, dass man zuerst auf die Idee gekommen ist eine spezielle CPU zu bauen, die es erlaubt unsicheren code sicher auszuführen, anstatt einfach nur zwangsläufig sicheren code auszuführen.



    2 mal bearbeitet, zuletzt am 27.09.18 14:18 durch patrik.stutz.

  14. Re: Uhm

    Autor: qwertü 27.09.18 - 14:36

    Noren schrieb:
    --------------------------------------------------------------------------------
    > Allerdings sehe ich immer noch
    > Sicherheitsprobleme bei jeglichen Schnittstellen. Nehmen wir an, WASM hätte
    > eine Schnittstelle/Call/Syscall oder was auch immer um mit einem FileSystem
    > zu interagieren (was z.B. bei Webservern üblich ist), so müsste zwangsweise
    > WASM oder der Webserver oder selber Sicherheitsmechanismen enthalten damit
    > dieser nur auf einen bestimmten vorgesehenen Teil zugreifen kann.

    Genau, aber es steht ja der Laufzeitumgebung (wasmjit) frei, welche API sie an den ausgeführten Code weitergibt. Sie kann ja zur Compile-Zeit prüfen, welche Funktionen der Code aufrufen möchte.

  15. Re: Uhm

    Autor: Noren 27.09.18 - 14:44

    Ich werde es mir auch noch genauer ansehen, allerdings befürchte ich das mehr möglich ist als nur übliche Web APIs und das da nahezu fast alles erlaubt ist, da der Kontext der Ring 0 ist und nicht der Userspace.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Bundeskriminalamt Wiesbaden, Meckenheim
  2. Nord-Micro GmbH & Co. OHG a part of Collins Aerospace, Frankfurt am Main
  3. über duerenhoff GmbH, Raum Pfaffenhofen
  4. Deutsche Lufthansa AG, Frankfurt am Main

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 159,90€ (Bestpreis!)
  2. (u. a. HP Pavilion 32 Zoll Monitor für 229,00€, Steelseries Arctis Pro wireless Headset für 279...
  3. ab 62,99€
  4. (aktuell u. a. HyperX Alloy Elite RGB Tastatur für 109,90€, Netgear EX7700 Nighthawk X6 Repeater)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Social Engineering: Die Mitarbeiter sind unsere Verteidigung
Social Engineering
"Die Mitarbeiter sind unsere Verteidigung"

Prävention reicht nicht gegen Social Engineering und die derzeitigen Trainings sind nutzlos, sagt der Sophos-Sicherheitsexperte Chester Wisniewski. Seine Lösung: Mitarbeiter je nach Bedrohungslevel schulen - und so schneller sein als die Kriminellen.
Ein Interview von Moritz Tremmel

  1. Social Engineering Mit künstlicher Intelligenz 220.000 Euro erbeutet
  2. Social Engineering Die unterschätzte Gefahr

Mi Note 10 im Hands on: Fünf Kameras, die sich lohnen
Mi Note 10 im Hands on
Fünf Kameras, die sich lohnen

Mit dem Mi Note 10 versucht Xiaomi, der Variabilität von Huaweis Vierfachkameras noch eins draufzusetzen - mit Erfolg: Die Fünffachkamera bietet in fast jeder Situation ein passendes Objektiv, auch die Bildqualität kann sich sehen lassen. Der Preis dafür ist ein recht hohes Gewicht.
Ein Hands on von Tobias Költzsch

  1. Xiaomi Neues Redmi Note 8T mit Vierfachkamera kostet 200 Euro
  2. Mi Note 10 Xiaomis neues Smartphone mit 108 Megapixeln kostet 550 Euro
  3. Mi Watch Xiaomi bringt Smartwatch mit Apfelgeschmack

Kognitive Produktionssteuerung: Auf der Suche nach dem Universalroboter
Kognitive Produktionssteuerung
Auf der Suche nach dem Universalroboter

Roboter erledigen am Band jetzt schon viele Arbeiten. Allerdings müssen sie oft noch von Menschen kontrolliert und ihre Fehler ausgebessert werden. Wissenschaftler arbeiten daran, dass das in Zukunft nicht mehr so ist. Ziel ist ein selbstständig lernender Roboter für die Automobilindustrie.
Ein Bericht von Friedrich List

  1. Ocean Discovery X Prize Autonome Fraunhofer-Roboter erforschen die Tiefsee

  1. Google Stadia im Test: Stadia ist (noch) kein Spiele-PC- oder Konsolenkiller
    Google Stadia im Test
    Stadia ist (noch) kein Spiele-PC- oder Konsolenkiller

    Tschüss, Downloads, Datenträger und Installationsroutinen: Mit Google Stadia können wir einfach losspielen. Beim Test hat das unter Echtweltbedingungen schon ziemlich gut geklappt - trotz der teils enormen Datenmengen und vielen fehlenden Funktionen.

  2. Logitech G: Kleine und große Knöpfe für den Xbox Adaptive Controller
    Logitech G
    Kleine und große Knöpfe für den Xbox Adaptive Controller

    Speziell für den Adaptive Controller bringt Logitech eine Auswahl an Knöpfen und Triggern als Komplettset auf den Markt. Das Adaptive Gaming Kit wird per Klinkenbuchse angeschlossen und soll auch Menschen mit Behinderung zum Spielen verhelfen.

  3. Telekom: T-Mobile US setzt seinen Starmanager John Legere ab
    Telekom
    T-Mobile US setzt seinen Starmanager John Legere ab

    Der Mann in der Lederjacke, der T-Mobile US ein neues erfolgreiches Image gegeben hat, verlässt das Unternehmen. Doch John Legere setzt sich nicht zur Ruhe.


  1. 18:00

  2. 17:52

  3. 17:38

  4. 17:29

  5. 16:55

  6. 16:43

  7. 16:30

  8. 16:15