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.

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Haufe Group, Bielefeld
  2. Die Etagen GmbH, Osnabrück
  3. BWI GmbH, verschiedene Einsatzorte
  4. Rational AG, Landsberg am Lech

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 98,99€ (Bestpreis!)
  2. 334,00€
  3. 469,00€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Zulassung autonomer Autos: Der Mensch fährt besser als gedacht
Zulassung autonomer Autos
Der Mensch fährt besser als gedacht

Mehrere Jahre haben Wissenschaftler und Autokonzerne an Testverfahren für einen Autobahnpiloten geforscht. Die Ergebnisse sprechen für den umfangreichen Einsatz von Simulation. Und gegen den schnellen Einsatz der Technik.
Von Friedhelm Greis

  1. Einride T-Pod Autonomer Lkw fährt in Schweden Waren aus
  2. Ingolstadt Audi vernetzt Autos mit Ampeln
  3. Wasserkühlung erforderlich Leistungshunger von Auto-Rechnern soll stark steigen

Azure Speech Service: Microsofts Demos entstehen im fensterlosen Nerd-Keller
Azure Speech Service
Microsofts Demos entstehen im fensterlosen Nerd-Keller

Build 2019 Moderne Architektur, große Fenster, ein Zen-Garten: Microsofts Campus wirkt außen modern und aufgeräumt. Präsentationen entstehen trotzdem in einem fensterlosen Raum, in dem sich Hardware und Werkzeug stapeln. Microsoft zeigt dort auch eine ungeskriptete Version seiner Spracherkennungssoftware.
Von Oliver Nickel

  1. Beta Writer Algorithmus schreibt wissenschaftliches Buch
  2. Google Neuer KI-Rat soll Googles ethische Richtlinien umsetzen
  3. Affectiva KI erkennt die Gefühle von Autofahrern

Das andere How-to: Deutsch lernen für Programmierer
Das andere How-to
Deutsch lernen für Programmierer

Programmierer schlagen sich ständig mit der Syntax und Semantik von Programmiersprachen herum. Der US-Amerikaner Mike Stipicevic hat aus der Not eine Tugend gemacht und nutzt sein Wissen über obskure Grammatiken, um Deutsch zu lernen.
Von Mike Stipicevic

  1. Programmiersprachen, Pakete, IDEs So steigen Entwickler in Machine Learning ein
  2. Software-Entwickler Welche Programmiersprache soll ich lernen?

  1. Customer First: SAP-Anwender sind in der Landschaft gefangen
    Customer First
    SAP-Anwender sind in der Landschaft gefangen

    SAP-Kunden sind treu, weil sie die eingeführte SAP-Landschaft nicht so einfach ablösen können. Doch sie bleiben auch deswegen, weil die Geschäftsprozesse gut unterstützt werden.

  2. Konsolenleak: Microsoft stellt angeblich nur Specs der nächsten Xbox vor
    Konsolenleak
    Microsoft stellt angeblich nur Specs der nächsten Xbox vor

    Die Veröffentlichungstermine von Spielen wie Cyberpunk 2077 und Gears 5, dazu die wichtigsten Spezifikationen der nächsten Xbox möchte Microsoft laut einem Leak während der Pressekonferenz auf der E3 vorstellen. Gerüchte gibt es auch über die Streamingpläne von Nintendo.

  3. FCC: Regulierer für Übernahme von Sprint durch T-Mobile US
    FCC
    Regulierer für Übernahme von Sprint durch T-Mobile US

    Nach offenbar weitgehenden Zugeständnissen beim Netzausbau auf dem Land und bei 5G hat der Regulierer in den USA dem Kauf von Sprint zugestimmt. Für die Telekom steigen damit die Kosten.


  1. 18:21

  2. 18:06

  3. 16:27

  4. 16:14

  5. 15:59

  6. 15:15

  7. 15:00

  8. 14:38