Fil-Cがsetjmp/longjmpとucontextをメモリ安全にする

メモリ安全なC方言であるFil-Cは、スタック破損やケイパビリティ違反なしにsetjmp/longjmpとucontext API（setcontext、getcontext、makecontext、swapcontext）をサポートするようになりました。この機能はリリース0.680で導入され、ソースからビルドする際に利用可能です。

コンテキストAPIの問題点

これらのAPIは、誤用によりダングリングスタックを復元する可能性があるため、非常に危険です。一般的なバグには以下があります：

• 関数内でsetjmpまたはgetcontextを呼び出した後、戻ってしまう——保存されたコンテキストはもはや存在しないスタックフレームを指している。
• スレッドを終了した後、解放されたスタックで実行を復元しようとする。
• スタック上でmakecontextを使用してコンテキストを作成し、そのスタックを解放した後、swapcontextまたはsetcontextでそこに切り替える。
• 現在実行中のコンテキストをswapcontextの第二引数として渡す（自分自身に切り替える）。

標準C（「Yolo-C」）では、これらのバグは静的なスタック破損、デバッグが困難なクラッシュ、および潜在的なセキュリティエクスプロイトを引き起こします。Fil-Cでは、このようなケースはすべて誤用の時点でパニックを発生させます。

Fil-Cがメモリ安全性を実現する方法

Fil-Cのアプローチはsetjmp/longjmpとucontextで異なります。setjmp/longjmpの場合、主な課題はsetjmpが二度戻ることです——呼び出された時とlongjmpの後。コンテキストを保存する動作は、コンパイラがvolatile注釈付き変数を正しく扱う必要があることを意味しますが、Fil-Cはコンテキストの復元が解放されたメモリや無効なメモリにアクセスしないことを保証します。

ucontextの場合、Fil-Cはスタックを管理し、操作を合法にするか、パニックにするかのいずれかです。ダングリングスタックフレームはそもそも不可能だからです。

例：Fil-Cでのsetjmp/longjmp

次のプログラムは動作を示しています：

#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;
}

これはx = 666を出力して終了します。volatileがない場合、コンパイラは最適化して代わりに42を出力する可能性があります。Fil-Cは最適化のセマンティクスを変更しませんが、メモリ破損を防止します。

誰のため？

ucontextベースのコルーチン（例：Boost fibers）やsetjmp/longjmpをCプログラムでの例外処理に使用し、メモリ安全性を求める開発者向けです。