Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Programmiersprache: Rust…

C/C++ scheint alternativlos. Oder: was wir von LLVM gelernt haben.

  1. Thema

Neues Thema Ansicht wechseln


  1. C/C++ scheint alternativlos. Oder: was wir von LLVM gelernt haben.

    Autor: kim3000 16.05.15 - 16:32

    Am tollsten finde ich die Entwicklung von LLVM. Damit sind dann eigentlich die ganzen dummen Diskussionen ueber Programmiersprachen beendet. Nur merken das Viele noch nicht.
    In welcher Sprache man seinen Code schreibt ist eigentlich irrelevant. Die Frage ist, wie gut ist LLVM optimiert um diesen Code in ein performantes Executable zu verwandeln.

    Ich finde die Diskussion sollte von Programmiersprachen weg. Die Frage ist doch eher, sollte man etwas nutzen, dass es einem in fahrlaessiger Weise erlaubt unsicheren Code zu schreiben.
    Rust beantwortet die Frage ja teilweise. Eine ordentliche Speicherverwaltung ist MUSS. Auch MUSS der Compiler wegen jedem Quark den man verbockt hat den Dienst verweigern! MUSS! Es gibt KEINE Entschuldigung fuer low-level Sicherheitsluecken! Eine Toolchain (Compiler etc.) der low-level Sicherheitsluecken zulaesst MUSS verboten werden!

    Wir haben jeden Monat tausende Sicherheitsluecken in populaerer Software. Man muss diese Sicherheitsluecken nehmen und jede so abarbeiten, dass die Toolchain so veraendert wird, dass diese Sicherheitsluecken auch bei einem besoffenen Programmierer von der Toolchain nicht zugelassen werden! Und dann schreibt man einen Test fuer die Toolchain, der diese Sicherheitsluecke versucht an der Toolchain vorbeizuschleusen.

    Und wenn das nicht moeglich ist, wenn man die Toolchain nicht "FIXEN" kann, dann sollte man sich mal ernsthaft Gedanken machen was fuer einen ranzigen Scheiss man da eigentlich benutzt und wie eine Toolchain aussehen muesste die diesen Mindestanforderungen entspricht.

    Ich denke das waere der richtige Weg anstatt wegen Performanceunterschieden im einstelligen Prozentbereich rumzuheulen.

  2. Re: C/C++ scheint alternativlos. Oder: was wir von LLVM gelernt haben.

    Autor: theonlyone 16.05.15 - 16:57

    Unsichere Software ist das eine, man kann auch argumentieren das für normale Anwender Software solche Bugs eigentlich egal sein "sollten" , wenn das OS verhindert das damit Schaden angerichtet wird, sprich wirklich wichtige Informationen nicht zugänglich macht, indem wirklich physisch ein anderer Speicher dafür genutzt wird, alles in Sandboxen läuft etc pp.

    Richtig blöd wirds ja, wenn ein Konzept wie eine Sandbox plötzlich doch ausgehebelt wird, weil ein Fehler im OS das erlaubt.

    Im Grunde muss das OS eben die Hürde für die Sicherheit sein, was die Anwendersoftware macht und tun will ist ja praktisch total egal, wenn sie nicht die Rechte hat das auch durchzuführen.

    Beim Thema Speicher wäre das z.B. das eine Anwendung klar sagen muss ich will X Ram haben und mehr gibts auch nicht. Zugriff auf low-level Speicher Operationen gibts garnicht.


    Das es, praktisch egal was du tust, immer irgendwelche Bugs geben wird die es doch schaffen deine Überprüfungen zu umgehen, das sollte einem dann aber auch klar sein.

  3. Re: C/C++ scheint alternativlos. Oder: was wir von LLVM gelernt haben.

    Autor: schap23 16.05.15 - 17:04

    Dummerweise muß man auch Betriebssysteme in irgendeiner Sprache schreiben.

  4. Re: C/C++ scheint alternativlos. Oder: was wir von LLVM gelernt haben.

    Autor: pythoneer 16.05.15 - 17:10

    theonlyone schrieb:
    --------------------------------------------------------------------------------
    > Richtig blöd wirds ja, wenn ein Konzept wie eine Sandbox plötzlich doch
    > ausgehebelt wird, weil ein Fehler im OS das erlaubt.

    Sandboxing ist kein Sicherheitskonzept.

    > Im Grunde muss das OS eben die Hürde für die Sicherheit sein, was die
    > Anwendersoftware macht und tun will ist ja praktisch total egal, wenn sie
    > nicht die Rechte hat das auch durchzuführen.

    Ich glaube du sprichst hier von zwei paar Schuhen. Es geht bei der Sicherheit der Speicherverwaltung nicht um Security. Es geht um dangling pointer, use after free .. etc.

    > Beim Thema Speicher wäre das z.B. das eine Anwendung klar sagen muss ich
    > will X Ram haben und mehr gibts auch nicht.

    Gibt es schon lange, nennt sich malloc. Aber darum geht es hier gar nicht.

    > Zugriff auf low-level Speicher Operationen gibts garnicht.

    Was sollen "low-level Speicher Operationen" sein? Pointerarithmetik?

    > Das es, praktisch egal was du tust, immer irgendwelche Bugs geben wird die
    > es doch schaffen deine Überprüfungen zu umgehen, das sollte einem dann aber
    > auch klar sein.

    Bei Rust geht es in erster Linie nicht um Bugs, die treten trotzdem auf. Ein Compiler kann dir nicht sagen ob dein Code Sinn macht. Er kann dich aber, wie bei Rust, davor bewahren unsicher mit Resourcen umzugehen um zum Beispiel Race conditions aus zu schließen.

    Der Rustcompiler wird nicht umsonst scherzhaft anstatt Compiler "Complainer" genannt. Die ersten Stunden mit dem Rustcomplainer sind echt die Hölle. Aber nach ner weile hat man den dreh raus. Rust bindet die Konzepte in die Sprache ein, die man jetzt so langsam in C++ nachschustert. Movesematik, ownership durch smartpointer etc.



    1 mal bearbeitet, zuletzt am 16.05.15 17:14 durch pythoneer.

  5. Re: C/C++ scheint alternativlos. Oder: was wir von LLVM gelernt haben.

    Autor: thomas001le 16.05.15 - 20:14

    Was soll die toolchain den garantieren? keine illegalen Speicherzugriffe? Das kann man ja auch zur Laufzeit ziemlich gut prüfen, stackprotector&co sind ja alte Hüte.
    Und gehen deswegen Sicherheitslücken weg? nein, sicherlich nicht...wenn man ein Zertifikat falsch prüft, oder eine flag schlichtweg vergisst, helfen dir die besten statischen Checker nichts....davon abgesehen ich dein Problem eh unentscheidbar, machinell ALLES zu prüfen ist schlichtweg unmöglich...

  6. Re: C/C++ scheint alternativlos. Oder: was wir von LLVM gelernt haben.

    Autor: igor37 16.05.15 - 20:56

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > Ich glaube du sprichst hier von zwei paar Schuhen. Es geht bei der
    > Sicherheit der Speicherverwaltung nicht um Security. Es geht um dangling
    > pointer, use after free .. etc.

    Man möchte aber auch Memory Leaks verhindern, und die sind eben eine Sicherheitslücke.

  7. Re: C/C++ scheint alternativlos. Oder: was wir von LLVM gelernt haben.

    Autor: pythoneer 16.05.15 - 21:46

    igor37 schrieb:
    --------------------------------------------------------------------------------
    > Man möchte aber auch Memory Leaks verhindern, und die sind eben eine
    > Sicherheitslücke.

    Kannst du etwas mehr darüber sagen, in wie weit Memory Leaks im Userland zu Sicherheitslücken werden können? Für kurzlebige Programme sollte das eigentlich eh keine Rolle spielen, denn das OS sammelt allozierten Speicher wieder ein. Langlebige Programme könnten den gesamten Speicher "leerfressen" und zu abnormalem Verhalten führen. Ansonsten fällt mir auf die schnelle nichts ein, was die Sicherheit gefährden könnte – für Hinweise immer dankbar.

    EDIT: Außer natürlich, dass ein Angreifer über dieses Problem das Programm zum abstürzen bringen kann – DOS-Attacke.



    1 mal bearbeitet, zuletzt am 16.05.15 21:48 durch pythoneer.

  8. Re: C/C++ scheint alternativlos. Oder: was wir von LLVM gelernt haben.

    Autor: Nephtys 17.05.15 - 09:27

    thomas001le schrieb:
    --------------------------------------------------------------------------------
    > Was soll die toolchain den garantieren? keine illegalen Speicherzugriffe?
    > Das kann man ja auch zur Laufzeit ziemlich gut prüfen, stackprotector&co
    > sind ja alte Hüte.
    > Und gehen deswegen Sicherheitslücken weg? nein, sicherlich nicht...wenn man
    > ein Zertifikat falsch prüft, oder eine flag schlichtweg vergisst, helfen
    > dir die besten statischen Checker nichts....davon abgesehen ich dein
    > Problem eh unentscheidbar, machinell ALLES zu prüfen ist schlichtweg
    > unmöglich...


    Man sollte aber nicht wegen des Halteproblems aufhören, überhaupt Fehler zu prüfen. Jede automatische Erkennung von Code-Unzulänglichkeiten kann unzählige Fehler in Produktivsystemen in der Zukunft abfangen.

  9. Re: C/C++ scheint alternativlos. Oder: was wir von LLVM gelernt haben.

    Autor: Hello_World 17.05.15 - 16:10

    thomas001le schrieb:
    --------------------------------------------------------------------------------
    > Was soll die toolchain den garantieren? keine illegalen Speicherzugriffe?
    > Das kann man ja auch zur Laufzeit ziemlich gut prüfen, stackprotector&co
    > sind ja alte Hüte.
    Das ist keine Lösung des Problems, sondern Symptombehandlung. Während ein Buffer Overflow in einem C-Programm beispielsweise zur Ausführung beliebigen Codes führt, kommt es bei einer Prüfung der Arraygrenzen normalerweise zu einem Programmabbruch und somit zu einem Denial of Service. Das ist zweifellos eine Verbesserung, aber dennoch keine Lösung. Und deswegen sollte man nach Möglichkeit dafür sorgen, dass solche Fehlermöglichkeiten bereits zur Compilezeit ausgeschlossen werden. Das hat auch den netten Nebeneffekt, dass die Prüfungen zur Laufzeit keinen Speicher und keine CPU-Leistung mehr fressen.

    > Und gehen deswegen Sicherheitslücken weg? nein, sicherlich nicht...wenn man
    > ein Zertifikat falsch prüft, oder eine flag schlichtweg vergisst, helfen
    > dir die besten statischen Checker nichts....
    Ja, natürlich verschwinden dadurch Sicherheitslücken. Natürlich nicht alle, aber das hat auch keiner behauptet. Du argumentierst hier gegen einen Strohmann.

    > davon abgesehen ich dein
    > Problem eh unentscheidbar
    Das ist nicht nur nicht richtig, das ist nicht einmal falsch!

  1. Thema

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Proximity Technology GmbH, Hamburg
  2. DT Netsolution GmbH, Stuttgart
  3. Proximity Technology GmbH, Düsseldorf
  4. BWI GmbH, Bonn, Köln, Wilhelmshaven, Potsdam-Schwielowsee

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 279€ + Versand oder kostenlose Marktabholung (Bestpreis!)
  2. Aktionsprodukt ab 399€ kaufen und Coupon erhalten
  3. (aktuell u. a. Asus PG279Q ROG Monitor für 689€ und Corsair Glaive RGB für 34,99€ + Versand)
  4. (u. a. Acer Predator XB281HK + 40-Euro-Coupon für 444€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Endpoint Security: IT-Sicherheit ist ein Cocktail mit vielen Zutaten
Endpoint Security
IT-Sicherheit ist ein Cocktail mit vielen Zutaten

Tausende Geräte in hundert verschiedenen Modellen mit Dutzenden unterschiedlichen Betriebssystemen. Das ist in großen Unternehmen Alltag und stellt alle, die für die IT-Sicherheit zuständig sind, vor Herausforderungen.
Von Anna Biselli

  1. Datendiebstahl Kundendaten zahlreicher deutscher Firmen offen im Netz
  2. Metro & Dish Tisch-Reservierung auf Google übernehmen
  3. Identitätsdiebstahl SIM-Dieb kommt zehn Jahre in Haft

Projektorkauf: Lumen, ANSI und mehr
Projektorkauf
Lumen, ANSI und mehr

Gerade bei Projektoren werden auf Plattformen verschiedener Onlinehändler kuriose Angaben zur Helligkeit beziehungsweise Leuchtstärke gemacht - sofern diese überhaupt angegeben werden. Wir bringen etwas Licht ins Dunkel und beschäftigen uns mit Einheiten rund um das Thema Helligkeit.
Von Mike Wobker


    Mobilfunktarife fürs IoT: Die Dinge ins Internet bringen
    Mobilfunktarife fürs IoT
    Die Dinge ins Internet bringen

    Kabellos per Mobilfunk bringt man smarte Geräte am leichtesten ins Internet der Dinge. Dafür haben deutsche Netzanbieter Angebote für Unternehmen wie auch für Privatkunden.
    Von Jan Raehm

    1. Smart Lock Forscher hacken Türschlösser mit einfachen Mitteln
    2. Brickerbot 2.0 Neue Schadsoftware möchte IoT-Geräte zerstören
    3. Abus-Alarmanlage RFID-Schlüssel lassen sich klonen

    1. Windows 10: Windows-Defender-Dateien werden als fehlerhaft erkannt
      Windows 10
      Windows-Defender-Dateien werden als fehlerhaft erkannt

      Der System File Checker in Windows 10 markiert neuerdings Dateien des Windows Defender als fehlerhaft. Der Bug ist auch Microsoft bekannt. Das Problem: Die neue Version des Defenders verändert im Installationsimage verankerte Dateien. Der Hersteller will das mit einem Update von Windows 10 beheben.

    2. Keystone: Mechanische Tastatur passt Tastendruckpunkte den Nutzern an
      Keystone
      Mechanische Tastatur passt Tastendruckpunkte den Nutzern an

      Die auf Kickstarter finanzierte Keystone ist eine mechanische Tastatur mit Hall-Effekt-Schaltern. Diese können die Druckstärke registrieren. Eine Software ermöglicht es der Tastatur, das Tippverhalten der Nutzer zu analysieren und Druckpunkte entsprechend anzupassen.

    3. The Witcher: Erster Netflix-Trailer mit Geralt, Ciri, Triss und Striegen
      The Witcher
      Erster Netflix-Trailer mit Geralt, Ciri, Triss und Striegen

      Netflix stellt den ersten Trailer seiner Serie The Witcher vor. Henry Cavill als Geralt von Riva kämpft dabei gegen Monster und Menschen und verwendet Hexerzeichen, Pirouettenkampf und Zaubertränke. Einige Szenen erinnern an Passagen aus den Büchern.


    1. 13:00

    2. 12:30

    3. 11:57

    4. 17:52

    5. 15:50

    6. 15:24

    7. 15:01

    8. 14:19