Filip Pizlo pr\u00e4sentierte auf der Konferenz SPLASH'24 den offenen C\/C++ Compiler Fil-C, der Schutz vor Problemen bietet, die durch Speicherfehler verursacht werden. Das Projekt zielt darauf ab, vollst\u00e4ndige Kompatibilit\u00e4t mit bestehendem Code in den Sprachen C und C++ zu gew\u00e4hrleisten \u2013 zur sicheren Handhabung von Speicher reicht es aus, den vorhandenen Code einfach neu zu kompilieren. Der Compiler wurde mit Komponenten aus dem LLVM-Projekt erstellt und wird unter der Apache 2.0-Lizenz vertrieben. Die Runtime erfolgt unter der BSD-Lizenz. Im Gegensatz zum k\u00fcrzlich angek\u00fcndigten TrapC-Projekt, das sich noch in der Entwurfsphase befindet, ist der Fil-C Compiler bereits bereit, bestehenden Code zu kompilieren. <\/p>\n
Das Projekt bietet sicher im Speicher arbeitende Alternativen zu den Standard-C-Bibliotheken (libc) und C++ (libc++), basierend auf den Musl- und LLVM libc++-Bibliotheken. Unter anderem k\u00f6nnen in den kompilierten Programmen Funktionen wie Multithreading, Signalverarbeitung, Datei-Mapping in den Speicher (mmap), longjmp\/setjmp und Exception-Handling in C++ verwendet werden. Mit Fil-C k\u00f6nnen die Projekte bzip2, zip, pcre und ncurses ohne \u00c4nderungen kompiliert werden. Mit geringf\u00fcgigen Anpassungen ist die Compilation von OpenSSH, OpenSSL, CPython, SQLite, Lua, Curl, Lynx, jpeg6b, zsh, xzutils und simdutf m\u00f6glich. <\/p>\n
Der Schutz vor Speicherproblemen wird durch die Verwendung von 128-Bit MonoCaps-Zeigern mit Metadaten zur Typpr\u00fcfung und zur \u00dcberwachung der Puffergrenzen gew\u00e4hrleistet, sowie durch einen FUGC-Garbage-Collector, der alle Speicherzuweisungs- und -freigabebetriebe \u00fcberwacht. Bei Speicherfehlern wird die Anwendung sofort abgest\u00fcrzt, was das Ausnutzen m\u00f6glicher Schwachstellen verhindert. <\/p>\n
Es wird berichtet, dass die Kombination aus MonoCaps und FUGC dabei hilft, alle Fehler zu erfassen und zu blockieren, die mit Puffer\u00fcberl\u00e4ufen im Stack und Heap, dem Zugriff auf bereits freigegebenen Speicher, Race Conditions bei der Arbeit mit Zeigern sowie falscher Typverarbeitung (Type Confusion) im Kontext von der \u00dcberlappung von Zeigertypen und Nicht-Zeigertypen, Problemen beim dynamischen Linken und der fehlerhaften Verwendung von va_lists zusammenh\u00e4ngen. Dar\u00fcber hinaus \u00fcberpr\u00fcft Fil-C separat die Grenzen und Typen in den Buffern, die bei Systemaufrufen \u00fcbergeben werden. <\/p>\n
Die M\u00f6glichkeit, Fil-C zum Schutz bestehender Projekte zu verwenden, ohne deren Code neu schreiben oder spezielle Sprachkonstrukte einf\u00fchren zu m\u00fcssen, geht jedoch mit einer Leistungseinbu\u00dfe einher. In der aktuellen Entwicklungsphase sind die mit Fil-C kompilierten Programme etwa 1,5 bis 5 mal langsamer im Vergleich zu herk\u00f6mmlichen Compilern. Geplant ist die Durchf\u00fchrung von Optimierungen. Nach Abschluss dieser Arbeiten wird erwartet, dass der Code in den meisten F\u00e4llen nur um das 1,2-fache langsamer ausgef\u00fchrt wird, w\u00e4hrend in den ung\u00fcnstigsten Szenarien die Verlangsamung 1,5-fach nicht \u00fcberschreiten wird. Der Compiler unterst\u00fctzt derzeit nur die Linux-Plattform auf X86_64-Systemen. \u00c4ltere Versionen unterst\u00fctzten macOS und FreeBSD, jedoch wurde beschlossen, die Anstrengungen nicht zu verbreiten und zun\u00e4chst einen qualitativ hochwertigen libc-Port f\u00fcr eine Plattform vorzubereiten. <\/p>\n
Eine weitere Einschr\u00e4nkung von Fil-C ist die grunds\u00e4tzliche Ablehnung der Aufrechterhaltung der ABI-Kompatibilit\u00e4t f\u00fcr C\/C++-Code. Dies verhindert, dass der in Fil-C kompilierte Code mit Bibliotheken und Objektdateien, die von anderen Compilern erstellt wurden, verkn\u00fcpft werden kann. Die Methoden zum Aufrufen von Funktionen und das Verfahren zur dynamischen Verkn\u00fcpfung in Fil-C unterscheiden sich von den bestehenden Compilern und Linkern. Diese Entscheidung wird damit begr\u00fcndet, dass bei der Verkn\u00fcpfung mit unsicherem Code die Essenz des in Fil-C angebotenen Schutzes verloren geht und der Eindruck eines gesch\u00fctzten Programms entsteht \u2014 bei Vorhandensein von ABI-Kompatibilit\u00e4t w\u00fcrden Entwickler versucht sein, nur einzelne Dateien in Fil-C zu kompilieren, ohne sich um die Portierung des gesamten Projekts zu k\u00fcmmern. <\/p>\n
Das im Fil-C verwendete MonoCap-Mechanismus basiert auf der Verwendung von 16-Byte-Zeigern, bei denen neben der Speicheradresse auch ein Verweis auf ein Objekt angegeben wird, das Informationen \u00fcber die F\u00e4higkeiten (capability) enth\u00e4lt, wie die obere und untere Grenze des mit dem Zeiger assoziierten Puffers sowie ein Array, das die Datentypen definiert, die in jedem Speicherblock gespeichert sind (1 Byte mit Typinformationen (unset, int, ptr, free) f\u00fcr jeden 16-Byte-Speicherblock). Bei jedem Zugriff auf den Speicher \u00fcber einen Zeiger werden die Grenzen und der Typ \u00fcberpr\u00fcft (z. B. k\u00f6nnen in den Speicher mit dem Typ 'ptr' keine Daten mit dem Typ 'int' geschrieben werden und umgekehrt). <\/p>\n
Alle Speicherzuweisungs- und -freigabeverfahren werden vom FUGC (Fil’s Unbelievable Garbage Collector) verwaltet, der beim Freigeben von Speicher alle mit dem freizugebenden Puffer verbundenen Typinformationen auf den Wert \u201efree\u201c setzt und dann alle Zeiger auf die freigegebenen Objekte auf ein separates Objekt umleitet, das signalisiert, dass der Speicher bereits freigegeben wurde. Jeglicher weitere Zugriff auf einen Datenblock mit dem Typ \u201efree\u201c oder \u00fcber einen Zeiger, der mit dem freigegebenen Objekt verbunden ist, f\u00fchrt zur Generierung einer Ausnahme, was hilft, vor Verwendung nach Freigabe (use-after-free) zu sch\u00fctzen. Der Garbage Collector arbeitet parallel und unterbricht nicht die Ausf\u00fchrung anderer Threads. <\/p>\n
Die Verwendung einer Kombination aus MonoCaps und FUGC erm\u00f6glicht es, die gewohnte Arbeit mit Zeigern zu erhalten und die Semantik der Aufrufe von malloc und free unver\u00e4ndert zu lassen, w\u00e4hrend gleichzeitig ein garantierter Schutz gew\u00e4hrleistet wird. Der Programmcode kann verschiedene logische Fehler enthalten, wie z. B. falsche Typumwandlungen, fehlerhafte arithmetische Operationen mit Zeigern, Race Conditions und eine versp\u00e4tete Aufruf von free(). Ungeachtet dessen wird Fil-C die urspr\u00fcnglichen Grenzen und Datentypen speichern und die Ausf\u00fchrung unterbrechen, wenn versucht wird, \u00fcber einen Zeiger auf einen Bereich au\u00dferhalb der gespeicherten Grenzen zuzugreifen, auf einen freigegebenen Speicherblock zuzugreifen oder Daten vom Typ \u201eint\u201c als Zeiger oder umgekehrt zu lesen. <\/p>\n
Fil-C, Filip Pizlo, ist Direktor bei Epic Games und verantwortlich f\u00fcr Projekte im Zusammenhang mit Programmiersprachen. Filip bringt umfangreiche Erfahrungen in der Arbeit mit virtuellen Maschinen, Programmiersprachen, Compilern und Garbage Collectors mit. So entwickelte er bei IBM die Programmiersprache X10, arbeitete bei Microsoft an den Garbage Collectors Stopless, Clover und Chicken, und war bei Apple f\u00fcr den JIT-Compiler sowie die Optimierung der Browser-Engine WebKit zust\u00e4ndig. Bei Epic Games leitet er das Team, das die Programmiersprache Verse und die zugeh\u00f6rige virtuelle Maschine entwickelt. Filip ist auch einer der Hauptentwickler von virtuellen Maschinen<\/a> Jikes RVM, Ovm und Fiji VM. \r\n ![\"Video](\"https:\/\/img.youtube.com\/vi\/_VF3pISRYRc\/hqdefault.jpg\")
\r\n