Fil-C가 setjmp/longjmp와 ucontext를 메모리 안전하게 만듦

Fil-C, 메모리 안전 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 개발자 중 메모리 안전성을 원하는 분들.