Cyclone: C ohne Buffer-Overflows

[Yalu X. (yalu) (Moderator)]

Ich bin zufälligerweise auf die Programmiersprache Cyclone gestoßen, die
evtl. für den einen oder anderen ambitionierten C-Programmierer (oder
vielleicht sogar C-Hasser) interessant sein könnte. Die Sprache ist sehr
C-ähnlich und der zugehörige Compiler eng mit dem GCC verbunden (was
auch der Grund ist, dass ich das im GCC-Forum poste):

  http://cyclone.thelanguage.org/

  http://en.wikipedia.org/wiki/Cyclone_%28programming_language%29

Hier gibt ja immer wieder lebhafte Diskussionen über die Stärken und
Schwächen von C, wobei immer wieder folgenden wichtigen Argumente
hervorgebracht werden:

- C-Befürworter: C erlaubt die nahezu vollständige Ressourcenkontrolle
  über das System und ist damit gut für die Systemprogrammierung
  geeignet.

- C-Gegner: C-Programme sind anfällig gegenüber Speicherkorruption auf
  Grund von Buffer-Overflows, ungültigen Pointern u.ä.

Cyclone hat sich zum Ziel gesetzt, das Speicherkorruptionsproblem von C
weitgehend zu beseitigen und trotzdem eine mit C vergleichbare
Ressourcenkontrolle zu bieten. Zudem lassen sich bestehende C-Programme
relativ leicht portieren, weil sowohl die Syntax als auch die
Standardbibliothek sehr C-ähnlich sind.

Ich habe mir die Sache mal etwas näher angeschaut und bin zum Ergebnis
gelangt, dass man Cyclone tatsächlich als ein "besseres C" ansehen kann.

Insbesondere das neue Pointer-Konzept macht auf mich einen sehr
durchdachten Eindruck:

  http://cyclone.thelanguage.org/wiki/Cyclone%20for%20C%20Programmers/#Pointers

Zusammen mit dem Konzept der "Regions"

  http://cyclone.thelanguage.org/wiki/Cyclone%20for%20C%20Programmers/#Regions

wird es dem Programmierer wirklich praktisch unmöglich gemacht,
speicherkorrumpierenden Code zu schreiben. Trotzdem muss er nicht auf
Späße wie Pointer-Arithmetik u.ä. (natürlich nur in streng limitierter
Form) verzichten. Daneben bietet Cyclone noch einige weitere
interessante Features:

  http://cyclone.thelanguage.org/wiki/User%20Manual/

Da GCC als Back-End verwendet wird und der Cyclone-Compiler auch als
Cross-Compiler gebaut werden kann (für ARM-Prozessoren ist das wohl auch
schon gemacht worden), sollte mit entsprechender Zeitinvestition
prinzipiell auch ein Einsatz für AVRs möglich sein. Die meisten der neu
hinzugekommenen Features sind recht speicher- und rechenzeitfreundlich
(aufwendigere Dinge wie Garbage-Collection und dergleichen kann man auch
weglassen). Angepasst werden müsste neben dem Cyclone-nach-C-Compiler
natürlich auch die AVR-LibC.

Nach so vielen tollen Infos nun noch ein paar Wermutstropfen (nicht,
dass jemand auf die Idee kommt, ich würde Werbung machen):

Leider scheint die Entwicklung von Cyclone seit einiger Zeit zu ruhen:
Der letzte SVN-Commit ist von 2009, der letzte Wiki-Eintrag auf der
Cyclone-Webseite von 2011. Da GCC als Back-End verwendet wird, kommt man
aber immerhin bei der Codegenerierung immer in den Genuss der neuesten
Entwicklungen.

Zudem ist es leider ein ziemliches Gefrickel, den Cyclone-Compiler mit
Bibliotheken aus den Sourcen zu bauen, wenn man nicht genau die gleichen
Versionen von gcc, glibc und binutils zur Verfügung hat, für die der
Compiler damals entwickelt wurde.

Der Compiler ist auch nicht für 64-Bit-Hosts gemacht. Da müsste man wohl
noch etwas mehr Hand anlegen.

Nachdem ich es aber trotz dieser Hürden gestern Abend geschafft habe,
das Ding auf einem älteren 32-Bit-Linux-PC zum Laufen zu bringen, und
ich erstmals ein paar Testprogrämmchen kompilieren und ausführen konnte,
war das Aha-Erlebnis schon ansehnlich. Sollte mir in nächster Zeit mal
langweilig sein, werde ich versuchen, das Ganze etwas geradezuziehen und
vielleicht erste Experimente mit dem AVR als Target unternehmen.

[Klaus W. (mfgkw)]

Wenn du es testest und glaubhaft versicherst, daß es so effizient ist 
wie C, schaue ich es mir an :-)

Ich habe den Verdacht, daß die Sicherheit irgendwo ihren Haken hat.
Mit den unterschiedlichen Arten von Zeigern ist es vielleicht nicht so 
schlimm im Schnitt, aber auch nicht kostenlos.

[Konrad S. (maybee)]

Es wundert mich nicht, dass das Projekt etwas vor sich dahindümpelt. Ich 
denke, es besteht kein wirklicher Bedarf für noch eine C-ähnliche 
Sprache. Wer sich nicht wunde Finger an den scharfen Kanten von C holen 
will, nimmt Java, C-Sharp, PHP oder Vergleichbares. Andererseits gibt es 
(noch?) genügend alte C-Hasen, die sich von den "gefährlichen Pointern" 
nicht in die Flucht schlagen lassen.

Aber mach ruhig ein bisschen Werbung für die Sprache. Es ist gut, wenn 
es Alternativen gibt. Und es ist besser, wenn man die Alternativen 
kennt. Leider geht viel Neues unter, bevor es den für's Überleben 
nötigen Bekanntheitsgrad erreicht.

[Oliver S. (oliverso)]

Klaus Wachtler schrieb:
> Ich habe den Verdacht, daß die Sicherheit irgendwo ihren Haken hat.

Der klassische Haken ist halt immmer - it's just another programming 
language. Ohne Verbreitung, ohne Relevanz in weltweiten Beispielen und 
Foren, usw.

Das hat jetzt gar nichts mit der Qualität der Sprache zu tun, die mag 
brilliant sein. VHS hat sich bei den Videokassetten auch nicht 
durchgesetzt, weil das das beste System war, sondern weil es da die 
meisten XXXX-Videos gab.

Das ist halt der Weg der Geschichte...

Oliver

[Frank M. (ukw) (Moderator)]

Yalu X. schrieb:

> Cyclone hat sich zum Ziel gesetzt, das Speicherkorruptionsproblem von C
> weitgehend zu beseitigen und trotzdem eine mit C vergleichbare
> Ressourcenkontrolle zu bieten.

Ich habe mal über die Links, die Du angegeben hast, drübergeschaut. Sehr 
interessante Geschichte.

Aber ich habe irgendwie den Eindruck, dass Cyclone nicht die 
Unzulänglichkeiten der Programmiersprache auszumerzen versucht, sondern 
eher die Unzulänglichkeiten des Programmierers. Auf den Seiten werden 
auch Beispiele angegeben, wie bestimmte Operationen (NULL-Pointer-Check, 
Pointer-Arithmetik) in Cyclone adäquat in C geschrieben werden könnten, 
um denselben Effekt zu erreichen.

Da frage ich mich: Warum das nicht gleich in C so schreiben? Ein guter 
C-Programmierer baut solche Checks selbst ein, um z.B. eine Funktion, 
die mit übergebenen Pointern hantiert, wasserdicht zu bekommen. Dafür 
braucht man nicht erst Cyclone.

Mein Fazit: Es gibt nichts in Cyclone, was man nicht auch in C 
entsprechend formulieren könnte, wenn man "defensiv" programmiert. Daher 
halte ich Cyclone eher als eine Programmiersprache für nicht 
gewissenhaft genug arbeitende Programmierer. Cyclone vermittelt hier für 
mich eine scheinbare Sicherheit, die eher zur Unvorsichtigkeit des 
Programmierers "verführt" - nach dem Motto: Angeschnallt kann ich ja 
ruhig mit 200 gegen eine Wand fahren... passiert schon nichts.

C ist unbarmherzig, wenn man nicht diszipliniert arbeitet. Cyclone 
versucht hier, die Unzulänglichkeiten des Programmierers in den Griff zu 
bekommen. Jedoch schützt auch diese Sprache nicht vor der Dummheit des 
Programmierers.

[Dr. Sommer (Gast)]

Frank M. schrieb:
> Mein Fazit: Es gibt nichts in Cyclone, was man nicht auch in C
> entsprechend formulieren könnte,
Es gibt nichts in C, was man nicht auch in Brainf*ck bzw. als 
Turingmaschinen-States angeben könnte. Trotzdem macht das keiner. Der 
ganze Sinn von allen Programmiersprachen ist, dass man Dinge kürzer, 
eleganter und vor allem sicherer ausdrücken kann.

Frank M. schrieb:
> Ein guter C-Programmierer baut solche Checks selbst ein
Wenn er perfekt wie ein Roboter ist und es niemals vergisst... Fakt ist, 
die meisten Programmierer sind auch nur Menschen und machen Fehler. 
Deswegen gibt es Programmiersprachen, die auf solche Fehler prüfen; ob 
zur Laufzeit oder durch den Compiler. Mit dem Aufkommen besserer 
Computer macht es auch nichts, wenn der Compiler etwas mehr prüfen muss 
als die ersten C-Compiler...

[Yalu X. (yalu) (Moderator)]

Klaus Wachtler schrieb:
> Wenn du es testest und glaubhaft versicherst, daß es so effizient ist
> wie C, schaue ich es mir an :-)

Wenn man ein Cyclone-Programm mit einem schlampig programmierten 
C-Programm vergleicht, das bei ungeeigneten Eingabedaten eben auch mal 
crasht, ist die Effizienz von Cyclone sicher schlechter. Vergleicht man 
es jedoch mit einem C-Programm, das gegen alle Eventualitäten 
abgesichert ist, ist der Effizienzunterschied nicht sehr groß und kann – 
je nach Anwendungsfall – zugunsten von C, aber auch zugunsten von 
Cyclone ausfallen.

Ein Beispiel, wo Cyclone besser abschneidet:

Eine Funktion schreibt einen Telegramm-Header in die erste 4 Bytes eines 
übergebenen Byte-Arrays. Es muss also überprüft werden, ob das 
übergebene Array mindestens 4 ELemente hat. In Cyclone sieht die 
Funktionsdeklaration so aus:

void writeHeader(uint8_t *@numelts(4) *telegramm)

Damit kann der Compiler auf der Aufruferseite überprüfen, ob da 
tatsächlich ein Array mit mindestens 4 Elementen übergeben wird. Diese 
Überprüfung ist rein statisch und kostet keinerlei Ressourcen zur 
Laufzeit. In C ist hier eine bombensichere Überprüfung IMHO unmöglich, 
man kann aber bspw. zusätzlich zu telegram die Arraylänge übergeben 
und diese in der Funktion auf >4 abprüfen. Das kostet aber sowohl 
Speicher als auch Rechenzeit. Außerdem wird der Quellcode länger und 
unübersichtlicher.

Zusätzliche Kosten entstehen vor allem dadurch, dass Cyclone versucht, 
jede einzelne Funktion inhärent sicher zu machen, was evtl. dazu führt, 
dass Sicherheitsabfragen eingebaut werden müssen, die man in C guten 
Gewissens weggelassen hätte. Aber das gute Gewissen trügt eben manchmal, 
und Fakt ist eben, dass es Software mit Buffer-Overflows u.ä. gibt, 
obwohl sich der Programmierer sicher war, dass diese nicht eintreten 
können.

Die zusätzlichen Abfragen und der zusätzliche Speicher, der bspw. von 
den Fat-Pointern belegt wird, sind jetzt aber auch nicht so wild, da ein 
Programm ja i.Allg. zu weniger als 10% aus Pointer-Handling besteht. 
Gewöhnliche Berechnungen und dergleichen werden exakt gleich gehandhabt 
wie in C.

Zudem kann man, nachdem man ein Programms fertiggestellt hat und der 
Meinung ist, dass alle wirklich notwendigen Sicherheitsvorkehrungen 
implementiert sind, den Compiler veranlassen, nicht mehr zu meckern und 
auch nicht eigenmächtig weitere Abfragen einzubauen. Leider nicht 
möglich ist eine selektive Deaktivierung der Compiler-Überprüfung in 
einzelnen Programmabschnitten (für die dann der Programmierer 
verantwortlich ist) bspw. mit einem Spezialkommentar.

Konrad S. schrieb:
> Es wundert mich nicht, dass das Projekt etwas vor sich dahindümpelt. Ich
> denke, es besteht kein wirklicher Bedarf für noch eine C-ähnliche
> Sprache. Wer sich nicht wunde Finger an den scharfen Kanten von C holen
> will, nimmt Java, C-Sharp, PHP oder Vergleichbares.

Das sind ganz unterschiedliche Anwendungsfälle: C ist für System- und 
hardwarenahe Programmierung, Java, C# und PHP für Highlevel-Anwendungen. 
Für die Highlevel-Anwendungsentwicklung gibt es mittlerweile Sprachen 
wie Sand am Meer, nicht aber für die System- und hardwarenahe 
Programmierung.

Frank M. schrieb:
> Aber ich habe irgendwie den Eindruck, dass Cyclone nicht die
> Unzulänglichkeiten der Programmiersprache auszumerzen versucht, sondern
> eher die Unzulänglichkeiten des Programmierers.

Das ist richtig. So sind bspw. die ganzen Vulnerabilitäten in 
PC-Programmen letztendlich Fehler der jeweiligen Programmierer und nicht 
der verwendeten Programmiersprachen. Man kann auch in C perfekt sichere 
Software schreiben, nur unterstützt es den Programmierer darin lange 
nicht so gut wie höherleveligere Programmiersprachen. Mit Cyclone ist 
eine Sprache entstanden, die (gewünscht) low-level ist und trotzdem 
Unterstützung für die sichere Programmierung bietet.

> Da frage ich mich: Warum das nicht gleich in C so schreiben? Ein guter
> C-Programmierer baut solche Checks selbst ein, um z.B. eine Funktion,
> die mit übergebenen Pointern hantiert, wasserdicht zu bekommen.

Zum einen gibt es nicht nur gute C-Programmierer, zum anderen übersieht 
auch ein guter Programmierer die eine oder andere Schwachstelle.