Fil-C macht setjmp/longjmp und ucontext speichersicher

Fil-C, der speichersichere C-Dialekt, unterstützt nun setjmp/longjmp und die ucontext-APIs (setcontext, getcontext, makecontext, swapcontext) ohne Stack-Korruption oder Capability-Verstöße. Die Funktion wurde in Version 0.680 eingeführt und ist beim Bau aus dem Quellcode verfügbar.

Das Problem mit Kontext-APIs

Diese APIs sind berüchtigt unsicher, da Missbrauch einen hängenden Stack wiederherstellen kann. Häufige Fehler sind:

• Aufruf von setjmp oder getcontext in einer Funktion, dann Rückkehr – der gespeicherte Kontext zeigt auf einen nicht mehr existierenden Stack-Frame.
• Beenden des Threads und dann versuchen, die Ausführung auf einem freigegebenen Stack wiederherzustellen.
• Erstellen eines Kontexts mit makecontext auf einem Stack, Freigabe dieses Stacks, dann swapcontext oder setcontext darauf.
• Übergabe des aktuell ausgeführten Kontexts als zweites Argument an swapcontext (Vertauschen mit sich selbst).

In Standard-C („Yolo-C“) verursachen diese Fehler stille Stack-Korruption, schwer zu debuggende Abstürze und potenzielle Sicherheitslücken. In Fil-C führen alle derartigen Fälle zu einem Panic am Ort des Missbrauchs.

Wie Fil-C Speichersicherheit implementiert

Fil-Cs Ansatz unterscheidet sich für setjmp/longjmp und ucontext. Bei setjmp/longjmp besteht die zentrale Herausforderung darin, dass setjmp zweimal zurückkehrt – einmal beim Aufruf, erneut nach longjmp. Das Sichern des Kontexts bedeutet, dass der Compiler volatile-annotierte Variablen korrekt behandeln muss, aber Fil-C stellt sicher, dass die Wiederherstellung eines Kontexts niemals auf freigegebenen oder ungültigen Speicher zugreift.

Für ucontext verwaltet Fil-C Stacks so, dass die Operation entweder legal ist oder zu einem Panic führt, da hängende Stack-Frames einfach unmöglich sind.

Beispiel: setjmp/longjmp in Fil-C

Das folgende Programm demonstriert das Verhalten:

#include <setjmp.h>
#include <stdio.h>

int main(int argc, char** argv) {
    volatile int x = 42;
    jmp_buf jb;
    if (setjmp(jb)) {
        printf("x = %d\n", x);
        return 0;
    }
    x = 666;
    longjmp(jb, 1);
    printf("Should not get here.\n");
    return 1;
}

Dies gibt x = 666 aus und beendet das Programm. Ohne volatile könnte der Compiler optimieren und 42 ausgeben. Fil-C ändert die Optimierungssemantik nicht, verhindert aber in jedem Fall Speicherkorruption.

Für wen?

Entwickler, die ucontext-basierte Coroutinen (z. B. Boost-Fasern) oder setjmp/longjmp zur Ausnahmebehandlung in C-Programmen verwenden und Speichersicherheit wünschen.