Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Ersatz für C: Tor…

Ersatz für C: Tor…

  1. Thema

Neues Thema Ansicht wechseln


  1. Ersatz für C: Tor…

    Autor: chriskoli 03.04.17 - 16:34

    Muss es eine neue Programmiersprache sein, um zu vermeiden, dass durch Fehler z.B. Speicherlöcher in Tor zur Laufzeit auftreten könnten? Die Benutzung einer neuen Sprache gerade bei einer sicherheitskritischen Anwendung wie Tor kann wiederum sicherheitsrelevante Probleme entstehen lassen. Meiner Meinung nach böte sich, wenn man schon wechseln möchte eher Python oder aber auch C++ an. Man könnte aber auch mehr Unittests entwickeln, die die neuralgischen Punkte in der Anwendung besser durchtesten. Auch die Benutzung von Type Checks und anderer Prüfmechanismen böte sich an. Nicht zu vergessen das Erstellen von Coding Guidelines, die die Verwendung z.B. bekannter Funktionen untersagt bei denen man weiß, dass sie zu Problemen führen können. Auch könnten sich die Entwickler überlegen unter Verwendung von Design by Contract zu überprüfen ob an allen Stellen sich ein 'Objekt', bzw. eine Struktur (ihr schon, was ich mit Objekt meine - C ist ja nicht objektorientiert) in dem in dieser Situation erforderlichen Zustand befindet. Es wäre bestimmt auch nicht verkehrt durch Tests zu prüfen, ob man Speicherlöcher etc. provozieren kann.

  2. Re: Ersatz für C: Tor…

    Autor: nille02 03.04.17 - 16:47

    chriskoli schrieb:
    --------------------------------------------------------------------------------
    > wenn man schon wechseln möchte eher
    > Python oder aber auch C++ an.

    Das erst ist hoffentlich ein Witz und das zweite hat letztlich die selben Probleme. Aber da auch Go aus der engeren Auswahl ausgeschieden ist, haben sie wohl noch andere Anforderungen.

  3. Re: Ersatz für C: Tor…

    Autor: Boereck 03.04.17 - 17:21

    > Muss es eine neue Programmiersprache sein, um zu vermeiden, dass durch
    > Fehler z.B. Speicherlöcher in Tor zur Laufzeit auftreten könnten?

    Im Fall von C und C++ ist das die einzige Möglichkeit Speichersicherheit zu garantieren. Abgesehen von natürlich von Fehlern im Compiler oder Laufzeitsystem einer alternativen Sprache. Jede andere Maßnahme ist nur ein minimieren der Möglichkeit Sicherheitslöchern

    > Die Benutzung einer neuen Sprache gerade bei einer sicherheitskritischen
    > Anwendung wie Tor kann wiederum sicherheitsrelevante Probleme entstehen
    > lassen.

    Ja, eine Neuimplementierung birgt immer die Gefahr neue Fehler einzubringen. Es ist eine Abwägung ob es einem Wert ist dafür eine ganze Klasse von häufig ausgenutzten potentiellen Fehlern auszumerzen.
    Es gibt z.B. bei der Portierung zu Rust die Möglichkeit mittels Corrode (https://github.com/jameysharp/corrode) den C Quelltext in unsafe Rust zu portieren. Von da an kann man existierenden Code nach und nach manuell zu safe Rust refactoren. Es wird sich vermutlich nicht jeder Code ohne größere Änderungen zu safe Rust ändern lassen, aber die Wahrscheinlichkeit für Fehler wird geringer.

    Eine weitere Möglichkeit ist übrigens zu sagen, dass neue Teile einer Anwendung nur in Rust geschrieben werden, so dass der unsichere Anteil langsam schwindet.

    > Meiner Meinung nach böte sich, wenn man schon wechseln möchte eher
    > Python oder aber auch C++ an.

    Also Python und C++ haben ja wohl massiv unterschiedliche Charakteristiken. C++ scheidet komplett aus, wenn einem Speichersicherheit wichtig ist, denn es bietet quasi keinen Vorteil gegenüber C. Die Komplexität der Sprache bietet weitere mögliche Fehlerquellen. Python hat einen GC und damit Speichersicherheit, wird aber wohl schon aus Performance-Gründen ausscheiden. Von weiteren Fehlerquellen aus dynamischer Typisierung mal ganz zu schweigen.

    > Man könnte aber auch mehr Unittests
    > entwickeln, die die neuralgischen Punkte in der Anwendung besser
    > durchtesten. Auch die Benutzung von Type Checks und anderer Prüfmechanismen
    > böte sich an. Nicht zu vergessen das Erstellen von Coding Guidelines, die
    > die Verwendung z.B. bekannter Funktionen untersagt bei denen man weiß, dass
    > sie zu Problemen führen können. Auch könnten sich die Entwickler überlegen
    > unter Verwendung von Design by Contract zu überprüfen ob an allen Stellen
    > sich ein 'Objekt', bzw. eine Struktur (ihr schon, was ich mit Objekt meine
    > - C ist ja nicht objektorientiert) in dem in dieser Situation
    > erforderlichen Zustand befindet. Es wäre bestimmt auch nicht verkehrt durch
    > Tests zu prüfen, ob man Speicherlöcher etc. provozieren kann.

    Das alles sind gute Maßnahmen um C-Code sicherer zu machen. Aber die Garantie für Speichersicherheit bekommst du mit C einfach nicht. Zudem ist das Einhalten von Richtlinien anstrengend und bei manueller Prüfung fehleranfällig. Entweder man bindet sich formale Verifikation ans Bein (was bei einer bestehenden Codebasis vermutlich auch ein Kraftakt ist, der Änderungen am Code erfordern wird), oder wechselt gleich zu einer Sprache die Speichersicherheit garantiert.

  4. Re: Ersatz für C: Tor…

    Autor: Headcool 03.04.17 - 18:25

    Boereck schrieb:
    --------------------------------------------------------------------------------
    > Entweder man bindet sich formale Verifikation ans Bein (was
    > bei einer bestehenden Codebasis vermutlich auch ein Kraftakt ist, der
    > Änderungen am Code erfordern wird), oder wechselt gleich zu einer Sprache
    > die Speichersicherheit garantiert.

    Es gibt keine Sprache die Speichersicherheit garantiert. Du kannst davon ausgehen, dass jeder gängige JIT und Interpreter eine unzählige Fülle an Sicherheitslücken enthält.
    Wenn deine eigene Anwendung kleiner ist als der JIT/Interpreter den du verwendest, enthält sie wahrscheinlich auch weniger Sicherheitslücken.

    Ohne Laufzeitumgebung kriegst du momentan keine Speichersicherheit. Mit einer, hat die Laufzeitumgebung keine, weil am Ende ja nativer Code stehen muss.

    Speichersicherheit zur Compilezeit wie es Rust versucht ist nicht universell möglich wegen des Haltproblems. Es trotzdem eine Verbesserung, auch wenn ich nicht denke, dass eine so kleine Verbesserung eine neue Sprache rechtfertig.
    Eine bessere Möglichkeit Sicherheit zu erlangen ist bspw. Hardware-Control-Flow-Enforcement. Damit wird ROP und JOP unmöglich gemacht wenn es richtig implementiert ist und damit auch ein Großteil der Exploits hinfällig. Das Ganze ist von der Geschwindigkeit her gratis und die Sprache muss man auch nicht wechseln.

  5. Re: Ersatz für C: Tor…

    Autor: DragonHunter 03.04.17 - 23:46

    chriskoli schrieb:
    --------------------------------------------------------------------------------
    > einer Meinung nach böte sich, wenn man schon wechseln möchte eher
    > Python oder aber auch C++ an.

    Dein Ernst? Du schlägst als Ersatz für C eine Interpretersprache vor, deren Referenzimplementierung auf einen Interpreter setzt, der in C geschrieben wurde?...
    o.O

  6. Re: Ersatz für C: Tor…

    Autor: Boereck 04.04.17 - 09:40

    > Ohne Laufzeitumgebung kriegst du momentan keine Speichersicherheit. Mit
    > einer, hat die Laufzeitumgebung keine, weil am Ende ja nativer Code stehen
    > muss.

    Gib doch mal ein Beispiel wie bei safe Rust die Speichersicherheit verletzt werden kann. Das würde die Sprachentwickler sicher auch interessieren. Wenn du einen JIT verwendest kommt am Ende auch Nativer Code raus.

    > Speichersicherheit zur Compilezeit wie es Rust versucht ist nicht
    > universell möglich wegen des Haltproblems.

    Den Zusammenhang musst du mir jetzt erklären. Ich sehe keinen Zusammenhang zwischen den beiden. Du kannst zur Complezeit sehr wohl Aussagen über Speichersicherheit treffen ohne genau zu wissen ob ein Programm terminiert oder nicht. Das ist eine Frage der Konzepte der Sprache, bzw. wie die Sprache dich in den Möglichkeiten einschränkt.

    > Es trotzdem eine Verbesserung,
    > auch wenn ich nicht denke, dass eine so kleine Verbesserung eine neue
    > Sprache rechtfertig.

    Aus Security-Sicht würde ich das nicht als kleine Verbesserung abtun. Es werden im Augenblick so viele IoT / Embedded Systeme mit Internetanschluss auf den Markt geworfen, deren Systeme nicht aktualisiert werden. Jede Angriffsfläche mittels Buffer-Overflows ist meiner Meinung nach zu viel.

    Aus Sicht von saftety sei noch die durch das Typsystem ermöglichte Data-Race-Freiheit erwähnt.

    Ansonsten fühlt sich Rust, wenn man vorher C programmiert hat an wie eine Sprache aus einer anderen Ära. Gut, es ist auch eine Sprache aus einer anderen Ära. Die bietet außer der sicheren manuellen Speicherverwaltung vielleicht keine bahnbrechend neuen Konzepte aus der Programmiersprachen-Forschung, aber gegenüber C ist das ein erheblicher Fortschritt. Hier mal ein paar generelle Punkte die Rust bietet:

    * Ein starkes Typsystem inklusive Generics
    * Pattern matching
    * Typinferenz an vielen stellen
    * Zero-cost Abstraktionen, speziell Iteratoren, die filter/map/reduce artige Operationen z.B. Arrays oder andere Datentypen ermöglichen
    * Keine Header-Orgien mit hässlicher include Semantik
    * Kommt bereits mit einem Build-Werkzeug
    * Funktionierendes Library-Ökosystem mit zentraler SemVer basierten Abhängigkeitsverwaltung

    > Eine bessere Möglichkeit Sicherheit zu erlangen ist bspw.
    > Hardware-Control-Flow-Enforcement. Damit wird ROP und JOP unmöglich gemacht
    > wenn es richtig implementiert ist und damit auch ein Großteil der Exploits
    > hinfällig. Das Ganze ist von der Geschwindigkeit her gratis und die Sprache
    > muss man auch nicht wechseln.

    OK, also warten wir, bis Intel das Marktreif hat (man ist also erst einmal gebunden an Prozessoren dieser Firma) und die Compiler das alle unterstützen und hoffen, dass damit wirklich alle Fälle von Malware abgedeckt sind und Exploit-Schreiber nicht auf andere Ideen als ROP/JOP kommen mittels Speicherüberlauf Code einzuschleusen. Bei Server-Software reicht es oft auch schon ein Programm einfach zum Absturz bringen um wirtschaftlichen Schaden zu verursachen.

    Im Fall von Tor, werden die sicherlich ihren Nutzern nicht sagen sie sollten erst einmal warten und dann nur eine bestimmte Art von Prozessoren und nur in Desktop-Rechnern nutzen.

    Die CET Technologie ist zu begrüßen, aber hilft jetzt nicht, und ist mit Sicherheit auch nicht die einzige Lösung aller Probleme.

  7. Re: Ersatz für C: Tor…

    Autor: schily 04.04.17 - 10:17

    Eine Sprache, die Pattern Matching enthält ist heute schon veraltet und um sicher zu sein reicht es vermutlich nicht aus, Zeiger aus dem Sprachumfang zu entfernen, auch Arrays können ein Problem werden, wenn man keine Laufzeitumgebung hat, die alles seht langsam macht.

  8. Re: Ersatz für C: Tor…

    Autor: skade 04.04.17 - 17:29

    > Eine Sprache, die Pattern Matching enthält ist heute schon veraltet und um sicher zu sein reicht es vermutlich nicht aus, Zeiger aus dem Sprachumfang zu entfernen, auch Arrays können ein Problem werden, wenn man keine Laufzeitumgebung hat, die alles seht langsam macht.

    Klar, und deswegen hat Rust eben auch Arrays mit automatischem bounds-checking (slices).

  9. Re: Ersatz für C: Tor…

    Autor: Boereck 04.04.17 - 17:51

    > Klar, und deswegen hat Rust eben auch Arrays mit automatischem
    > bounds-checking (slices).

    Dazu sollte man sagen, dass das LLVM Backend in einigen Fällen das bounds-checking weg optimieren kann. Werden stattdessen die Iteratoren (zur Erinnerung: zero-cost Abstraktion) genutzt, fallen die bounds-checks generell weg.

  10. Re: Ersatz für C: Tor…

    Autor: Headcool 05.04.17 - 16:46

    Boereck schrieb:
    --------------------------------------------------------------------------------
    > Gib doch mal ein Beispiel wie bei safe Rust die Speichersicherheit verletzt
    > werden kann. Das würde die Sprachentwickler sicher auch interessieren. Wenn
    > du einen JIT verwendest kommt am Ende auch Nativer Code raus.

    Sogar ohne unsafe:
    http://www.tedunangst.com/flak/post/heartbleed-in-rust

    > Den Zusammenhang musst du mir jetzt erklären. Ich sehe keinen Zusammenhang
    > zwischen den beiden. Du kannst zur Complezeit sehr wohl Aussagen über
    > Speichersicherheit treffen ohne genau zu wissen ob ein Programm terminiert
    > oder nicht. Das ist eine Frage der Konzepte der Sprache, bzw. wie die
    > Sprache dich in den Möglichkeiten einschränkt.

    Das Halteproblem beschreibt letztendlich, dass es nicht möglich ist das dynamische Verhalten eines Programmes vorrauszusagen, zumindest nicht mit einer TM. Vielleicht finden wir irgendwann etwas das mächtiger ist als eine TM, aber das ignoriere ich jetzt mal. Wenn man nicht alles vorhersagen statisch vorhersagen kann muss man es dynamisch machen. Dann hat man wieder genau das Problem das ich eben erwähnt hatte. Am Ende ist alles nativ auch die Runtime Checks. Wer überprüft die jetzt? Überprüfen die sich selber? Was wenn da ein Fehler drinnen ist, verhindert dieser vielleicht, dass er selbst gefunden wird.

    > Aus Security-Sicht würde ich das nicht als kleine Verbesserung abtun. Es
    > werden im Augenblick so viele IoT / Embedded Systeme mit Internetanschluss
    > auf den Markt geworfen, deren Systeme nicht aktualisiert werden. Jede
    > Angriffsfläche mittels Buffer-Overflows ist meiner Meinung nach zu viel.

    Bei solchen System ist Performance so wichtig, sodass Rust sowieso nicht in Frage kommt. Und solange Rust unnötige Runtime Checks machen muss, die gar nicht nötig sind, wird sich das nicht ändern.
    Das Problem dieser Dinger ist weniger die Sprache als das Update-Verhalten. Die Teile gehören entweder vom öffentlichen Netz getrennt oder die Hersteller sollten sich zu x Jahre Maintaining verpflichten müssen.
    Im Ende eher eine gesetzliches als ein technisches Problem.

    > Aus Sicht von saftety sei noch die durch das Typsystem ermöglichte
    > Data-Race-Freiheit erwähnt.

    Das ist sicher nett. In Zeiten Von TSX aber nicht so sonderlich hilfreich.
    Ich muss ehrlich sagen, dass ich nie wirkliche Probleme mit nebenläufiger Programmierung hatte. Alle Daten auf die man von mehreren Threads zugreift werden mit einem mutex gesichert.

    > Ansonsten fühlt sich Rust, wenn man vorher C programmiert hat an wie eine
    > Sprache aus einer anderen Ära. Gut, es ist auch eine Sprache aus einer
    > anderen Ära. Die bietet außer der sicheren manuellen Speicherverwaltung
    > vielleicht keine bahnbrechend neuen Konzepte aus der
    > Programmiersprachen-Forschung, aber gegenüber C ist das ein erheblicher
    > Fortschritt. Hier mal ein paar generelle Punkte die Rust bietet:

    Rust leiht sich viele Elemente aus funktionalen Programmiersprachen. Funktionale Programmiersprachen haben sich aus einem guten Grund nicht durchgesetzt.

    > * Ein starkes Typsystem inklusive Generics

    Ein Rückschritt im Vergleich zu C++-Templates.

    > * Pattern matching

    Auf der einen Seite nett, auf der anderen Seite verleitet das zu funktionaler Programmierung die nicht sogut verständlich ist.

    > * Typinferenz an vielen stellen

    Nett, aber nicht unbedingt neues.

    > * Zero-cost Abstraktionen, speziell Iteratoren, die filter/map/reduce
    > artige Operationen z.B. Arrays oder andere Datentypen ermöglichen

    Dann erstell doch ein Array, verwende die reduce Funktion um alle Elemente bspw zu addieren und schau mir doch bitte nach ob das Endergebnis vektorisiert worden ist.
    Wenn das nicht der Fall ist, ist der Code um Faktoren langsamer als er sein könnte. Bei AVX512, 8bit-Integer und dem Fall, dass das Array gecachet ist, reden wir hier von Faktor 64.

    > * Keine Header-Orgien mit hässlicher include Semantik

    Ja zugegeben, das ist ein Problem in C und C++. Auf der anderen Seite ist es in diesen Sprachen deswegen sehr einfach möglich Funktionen über die ABI für andere Sprachen anzubieten.

    > * Kommt bereits mit einem Build-Werkzeug

    Hoff ich wohl.

    > * Funktionierendes Library-Ökosystem mit zentraler SemVer basierten
    > Abhängigkeitsverwaltung

    Nett, aber auch nicht wirklich neu.


    > OK, also warten wir, bis Intel das Marktreif hat (man ist also erst einmal
    > gebunden an Prozessoren dieser Firma) und die Compiler das alle
    > unterstützen und hoffen, dass damit wirklich alle Fälle von Malware
    > abgedeckt sind und Exploit-Schreiber nicht auf andere Ideen als ROP/JOP
    > kommen mittels Speicherüberlauf Code einzuschleusen. Bei Server-Software
    > reicht es oft auch schon ein Programm einfach zum Absturz bringen um
    > wirtschaftlichen Schaden zu verursachen.

    Normalerweise werden im Bereich der Befehlssätze nützliche Dinge relativ schnell überall implementiert.
    AMD bringt FMA heraus, Intel zieht nach. Intel bringt AES-NI heraus, AMD und ARM ziehen nach. ARM bringt SHA Extension raus, Intel zieht nach.
    Wenn wir davon ausgehen, dass in Intel das in 2-3Jahren implementiert hat, dann kann man davon ausgehen, dass es in 5 Jahren alle implementiert haben werden.
    Natürlich wird es andere Exploits geben, aber wesentlich weniger und wesentlich teuerer. Ich errinnere daran, dass der letzte Tor-Exploit aus genau diesem Grund nicht genutzt werden konnte, weil er sonst hätte veröffentlicht werden müssen.

    > Im Fall von Tor, werden die sicherlich ihren Nutzern nicht sagen sie
    > sollten erst einmal warten und dann nur eine bestimmte Art von Prozessoren
    > und nur in Desktop-Rechnern nutzen.

    Clang und MVSC unterstüzten schon heute eine software basierte Lösung für CFI.
    Hardware basiertes CFE ist natürlich besser und schneller, aber wenn es unbedingt nötig ist, dann nimmt man halt die Softwarelösung.

    > Die CET Technologie ist zu begrüßen, aber hilft jetzt nicht, und ist mit
    > Sicherheit auch nicht die einzige Lösung aller Probleme.

    Sage ich auch nicht. Aber ROP-Angriffe sind mWn die am meisten verwendeten Angriffe und könnten dadurch komplett eliminiert werden.

  11. Re: Ersatz für C: Tor…

    Autor: Boereck 05.04.17 - 23:17

    Also erst einmal: Deine Kommentare dass dieses oder jenes Rust feature nichts neues ist: Ich habe bereits darauf hingewiesen, dass Rust nicht die Innovation der PL-Theorie ist. Aber noch mal: Im Vergleich zu C ist es mehr als wesentlich angenehmer.

    > > Gib doch mal ein Beispiel wie bei safe Rust die Speichersicherheit
    > verletzt
    > > werden kann. Das würde die Sprachentwickler sicher auch interessieren.
    > Wenn
    > > du einen JIT verwendest kommt am Ende auch Nativer Code raus.
    >
    > Sogar ohne unsafe:
    > www.tedunangst.com

    Also das ist ja wohl ein Programmierfehler und nicht Speichersicherheit in Form von
    * Vergessen von Speicherfreigabe
    * Doppelter Speicherfreigabe
    * Über Grenzen von Arrays lesen und Schreiben
    * Dereferenzierung von freigegebenen und 0 Adressen

    Vor Logik-Bugs hilft auch Rust nicht.

    > Das Halteproblem beschreibt letztendlich, dass es nicht möglich ist das
    > dynamische Verhalten eines Programmes vorrauszusagen, zumindest nicht mit
    > einer TM. Vielleicht finden wir irgendwann etwas das mächtiger ist als eine
    > TM, aber das ignoriere ich jetzt mal. Wenn man nicht alles vorhersagen
    > statisch vorhersagen kann muss man es dynamisch machen. Dann hat man wieder
    > genau das Problem das ich eben erwähnt hatte. Am Ende ist alles nativ auch
    > die Runtime Checks. Wer überprüft die jetzt? Überprüfen die sich selber?
    > Was wenn da ein Fehler drinnen ist, verhindert dieser vielleicht, dass er
    > selbst gefunden wird.

    Streng genommen ist das Halteproblem das Problem, nicht feststellen zu können festzustellen ob ein Algorithmus terminiert. Wie du das jetzt auf Rusts Speichersicherheit mappen willst ist mir immer noch unklar.

    > Bei solchen System ist Performance so wichtig, sodass Rust sowieso nicht in
    > Frage kommt. Und solange Rust unnötige Runtime Checks machen muss, die gar
    > nicht nötig sind, wird sich das nicht ändern.

    Also bei dem Kram der Heutzutage alles am Internet hängt glaube ich das eher nicht. Zudem wird bei Rust das Meiste zur Compilezeit geprüft. Nur in Fällen in denen der Compiler nicht garantieren kann, dass du ein Array/Slice in den Grenzen referenzierst wird eine Panik erzeugt. In den Meisten fällen wird eh mit Iteratoren gearbeitet und die bounds checks gibt es in den Fällen nicht. Ich bezweifle stark, dass das in der überwiegenden Mehrheit der Programme zu größeren Performance-Einbußen führt. Aber da können wir vermutlich erst mal nur spekulieren. Wenn du ein ESP oder Airbag Controller für ein Auto umsetzt und jede Nanosekunde zählt, dann wird es vielleicht Kritisch. Für Smart-Home Appliances und ähnliches reichen für das Gros der Logik ja oft schon Scripte (abgesehen von der Ansteuerung von Aktuatoren). Nur die Interpreter verbrutzeln halt unnötig Energie.

    > Das Problem dieser Dinger ist weniger die Sprache als das Update-Verhalten.
    > Die Teile gehören entweder vom öffentlichen Netz getrennt oder die
    > Hersteller sollten sich zu x Jahre Maintaining verpflichten müssen.
    > Im Ende eher eine gesetzliches als ein technisches Problem.

    Das ist durchaus ein Kritisches Problem. Aber ein System was von Hause aus sicherer ist, wäre trotzdem besser als es andaurend Patchen zu müssen. Und geht ein Hersteller Pleite, dann nützt dir auch die gesetzliche Garantie nichts.

    > > Aus Sicht von saftety sei noch die durch das Typsystem ermöglichte
    > > Data-Race-Freiheit erwähnt.
    >
    > Das ist sicher nett. In Zeiten Von TSX aber nicht so sonderlich hilfreich.
    > Ich muss ehrlich sagen, dass ich nie wirkliche Probleme mit nebenläufiger
    > Programmierung hatte. Alle Daten auf die man von mehreren Threads zugreift
    > werden mit einem mutex gesichert.

    Also erst willst du das letzte Quäntchen Performance und dann sicherst du alles mit einem Mutex? Abgesehen davon muss man auch bei Mutexen noch genau wissen was man tut. Komplexe nebenläufige Programme sind nicht einfach, selbst wenn man höher levelige Abstraktionen wählt. Das wird auch in Rust der Fall sein, wo einem einige Fehler bereits durch das Typsystem erspart bleiben.

    > > * Ein starkes Typsystem inklusive Generics
    >
    > Ein Rückschritt im Vergleich zu C++-Templates.

    C++ Templates waren ja wohl lange Zeit ein Grauen. Zumindest wenn man sich mal einen Fehler erlaubt hat und dann durch Seitenweise unleserliche Fehlermeldungen wühlen musste. Zum Glück ist das mittlerweile besser.
    Falls es dich interessiert: In Rust sollten bald Pi-Types Einzug halten, die zumindest die aus Performance-Sicht wichtigen Teile aus C++ Templates übernehmen:
    https://github.com/rust-lang/rfcs/issues/1930

    > > * Zero-cost Abstraktionen, speziell Iteratoren, die filter/map/reduce
    > > artige Operationen z.B. Arrays oder andere Datentypen ermöglichen
    >
    > Dann erstell doch ein Array, verwende die reduce Funktion um alle Elemente
    > bspw zu addieren und schau mir doch bitte nach ob das Endergebnis
    > vektorisiert worden ist.
    > Wenn das nicht der Fall ist, ist der Code um Faktoren langsamer als er sein
    > könnte. Bei AVX512, 8bit-Integer und dem Fall, dass das Array gecachet ist,
    > reden wir hier von Faktor 64.

    Ich kann dir nicht sagen, was der Stand für Auto-Vektorisierung und Iteratoren in Rust ist, das kannst du gerne selbst mal Benchmarken oder dir die vom Compiler generierten Instruktionen anschauen. Ich weiß, dass daran gearbeitet wird, denn das ist auch einer der Gründe, weshalb Rust in Benchmarks gerne mal langsamer ist.
    Aber ich verweise auch gerne auf crates.io, da gibt es eine Menge SIMD/Data-Parallel Bibliotheken. Dann muss man aber expliziteren Code schreiben, der Compiler schenkt es einem dann nicht.

    > > * Kommt bereits mit einem Build-Werkzeug
    >
    > Hoff ich wohl.

    Nunja, ich meine nicht den Compiler. Wenn du in ein C-Projekt einsteigst musst du erst mal sehen, ob blanke Makefiles, oder Auto-Tools oder CMake verwendet wird.

    > Normalerweise werden im Bereich der Befehlssätze nützliche Dinge relativ
    > schnell überall implementiert.
    > AMD bringt FMA heraus, Intel zieht nach. Intel bringt AES-NI heraus, AMD
    > und ARM ziehen nach. ARM bringt SHA Extension raus, Intel zieht nach.
    > Wenn wir davon ausgehen, dass in Intel das in 2-3Jahren implementiert hat,
    > dann kann man davon ausgehen, dass es in 5 Jahren alle implementiert haben
    > werden.

    5 Jahre? Wenn ich jetzt sicher Programme haben will? Und nicht jeder wirft seinen Rechner weg wenn ein Prozessor mit einem sicheren Befehlssatz herauskommt. Was meinst du wie lange es dauert bis die Mehrheit der Geräte am Internet damit ausgestattet ist?

    > Natürlich wird es andere Exploits geben, aber wesentlich weniger und
    > wesentlich teuerer. Ich errinnere daran, dass der letzte Tor-Exploit aus
    > genau diesem Grund nicht genutzt werden konnte, weil er sonst hätte
    > veröffentlicht werden müssen.

    Ja, das glaube ich auch. Deswegen finde ich die Befehlserweiterungen ja auch gut.

    > Clang und MVSC unterstüzten schon heute eine software basierte Lösung für
    > CFI.
    > Hardware basiertes CFE ist natürlich besser und schneller, aber wenn es
    > unbedingt nötig ist, dann nimmt man halt die Softwarelösung.

    Na da bin ich mal auf die Performance von C mit Software CFI im Vergleich zu Rust Code ohne gespannt.

  12. Re: Ersatz für C: Tor…

    Autor: Boereck 06.04.17 - 10:46

    > Also bei dem Kram der Heutzutage alles am Internet hängt glaube ich das
    > eher nicht. Zudem wird bei Rust das Meiste zur Compilezeit geprüft. Nur in
    > Fällen in denen der Compiler nicht garantieren kann, dass du ein
    > Array/Slice in den Grenzen referenzierst wird eine Panik erzeugt.

    Korrektur: Es wird in dem Fall eine Laufzeitprüfung generiert und natürlich nur im Fehlerfall eine Panik erzeugt.

  1. Thema

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. LOTTO Hessen GmbH, Wiesbaden
  2. Technische Informationsbibliothek (TIB), Hannover
  3. Impactory GmbH, Darmstadt (Home-Office)
  4. INTENSE AG, Würzburg, Köln, Saarbrücken

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 64,90€ (Bestpreis!)
  2. (u. a. beide Spiele zu Ryzen 9 3000 oder 7 3800X Series, eines davon zu Ryzen 7 3700X/5 3600X/7...
  3. 279,90€


Haben wir etwas übersehen?

E-Mail an news@golem.de


iPad 7 im Test: Nicht nur für Einsteiger lohnenswert
iPad 7 im Test
Nicht nur für Einsteiger lohnenswert

Auch mit der siebten Version des klassischen iPads richtet sich Apple wieder an Nutzer im Einsteigersegment. Dennoch ist das Tablet sehr leistungsfähig und kommt mit Smart-Keyboard-Unterstützung. Wer ein gutes, lange unterstütztes Tablet sucht, kann sich freuen - ärgerlich sind die Preise fürs Zubehör.
Ein Test von Tobias Költzsch

  1. iPad Einschränkungen für Apples Sidecar-Funktion
  2. Apple Microsoft Office auf neuem iPad nicht mehr kostenlos nutzbar
  3. Tablet Apple bringt die 7. Generation des iPads

Gemini Man: Überflüssiges Klonexperiment
Gemini Man
Überflüssiges Klonexperiment

Am 3. Oktober kommt mit Gemini Man ein ambitioniertes Projekt in die deutschen Kinos: Mit HFR-Projektion in 60 Bildern pro Sekunde und Will Smith, der gegen sein digital verjüngtes Ebenbild kämpft, betreibt der Actionfilm technisch viel Aufwand. Das Seherlebnis ist jedoch bestenfalls komisch.
Von Daniel Pook

  1. Filmkritik Apollo 11 Echte Mondlandung als packende Kinozeitreise

Linux-Kernel: Selbst Google ist unfähig, Android zu pflegen
Linux-Kernel
Selbst Google ist unfähig, Android zu pflegen

Bisher gilt Google als positive Ausnahme von der schlechten Update-Politik im Android-Ökosystem. Doch eine aktuelle Sicherheitslücke zeigt, dass auch Google die Updates nicht im Griff hat. Das ist selbst verschuldet und könnte vermieden werden.
Ein IMHO von Sebastian Grüner

  1. Kernel Linux bekommt Unterstützung für USB 4
  2. Kernel Vorschau auf Linux 5.4 bringt viele Security-Funktionen
  3. Linux Lockdown-Patches im Kernel aufgenommen

  1. H2.City Gold: Caetanobus stellt Brennstoffzellenbus mit Toyota-Technik vor
    H2.City Gold
    Caetanobus stellt Brennstoffzellenbus mit Toyota-Technik vor

    Damit die Luft in Städten besser wird, sollen Busse sauberer werden. Ein neuer Bus aus Portugal mit Brennstoffzellenantrieb emititiert als Abgas nur Wasserdampf.

  2. Ceconomy: Offene Führungskrise bei Media Markt und Saturn
    Ceconomy
    Offene Führungskrise bei Media Markt und Saturn

    Die Diskussion um die mögliche Absetzung von Ceconomy-Chef Jörn Werner sollte eigentlich noch nicht öffentlich werden. Jetzt wissen es alle, und es gibt keinen Nachfolger.

  3. Polizei: Hunde, die nach Datenspeichern schnüffeln
    Polizei
    Hunde, die nach Datenspeichern schnüffeln

    Spürhunde können neben Sprengstoff und Drogen auch Datenspeicher oder Smartphones erschnüffeln. Die Polizei in Nordrhein-Westfalen hat kürzlich ihre frisch ausgebildeten Speicherschnüffler vorgestellt.


  1. 18:18

  2. 18:00

  3. 17:26

  4. 17:07

  5. 16:42

  6. 16:17

  7. 15:56

  8. 15:29