▲

Fil-C 사용에 대한 djb의 노트

 (cr.yp.to)
2P by GN⁺ 6달전 | ★ favorite | 댓글 1개
  • 메모리 안전성을 갖춘 새로운 C/C++ 컴파일러 Fil-C는 기존 코드와의 높은 호환성을 보이며, 대부분의 라이브러리와 애플리케이션이 수정 없이 작동
  • Debian 13 환경에서 Fil-C를 소스 빌드 및 설치하는 절차와, glibc·binutils를 Fil-C로 재컴파일하는 자동 설치 스크립트 제공
  • 약 9000개 암호화 소프트웨어 마이크로벤치마크에서 Fil-C는 clang 대비 1~4배의 사이클 수를 사용
  • Fil-C로 Debian 패키지 빌드 체계 통합을 시도하며, 새로운 ABI(amd64fil0)를 추가해 Fil-C 기반 패키지 병행 설치 가능 구조 제시
  • Fil-C는 메모리 안전성과 기존 생태계 호환성을 동시에 추구하며, Debian 기반 시스템으로의 확장 가능성을 보여줌

Fil-C 개요 및 초기 인상

  • Fil-C는 메모리 안전성을 보장하는 C/C++ 컴파일러로, 기존 코드와의 높은 호환성을 보임
    • 대부분의 라이브러리와 애플리케이션이 수정 없이 작동
    • 예외적으로 수정이 필요한 경우도 해결이 어려운 수준은 아님
  • 작성자는 관리 중인 여러 시스템을 Fil-C로 컴파일된 코드로 전환해 보호하는 것을 목표로 함
  • 테스트 환경은 Debian 13, AMD Ryzen 5 7640HS(6코어 12스레드), 12GB RAM, 36GB 스왑 메모리

관련 자료 및 스크립트

  • Fil-C와 상위 소스(예: clang, glibc) 간의 차이를 비교하는 감사용 diff 스크립트 공개
  • Debian 13에서 Fil-C, glibc, binutils를 다운로드·컴파일·설치하는 filian-install-compiler 스크립트 제공
    • 전체 실행 시간: 실시간 86분, 사용자 시간 477분, 시스템 시간 52분
  • Fil-C를 이용해 Debian 소스 패키지를 빌드하는 filian-install-packages 스크립트 제공
    • 일부 패키지(bzip2 등)는 정상 빌드 확인
  • Fil-C vs. clang 성능 그래프 공개
    • 약 9000개 암호화 관련 마이크로벤치마크 결과
    • Fil-C로 컴파일된 코드는 clang 대비 1~4배의 사이클 소모

Fil-C 설치 및 빌드

  • root 권한으로 필요한 패키지 설치 후, 비특권 사용자 filc로 빌드 수행
  • Fil-C 소스는 glibc 및 여러 고수준 라이브러리·애플리케이션을 포함
  • 빌드 명령: time ./build_all_fast_glibc.sh
    • musl도 선택 가능하지만 일부 패키지(attr, elfutils, sed, vim 등)와 비호환성 존재
  • 빌드 중 메모리 부족 발생 시 스왑 공간을 36GB로 확장해 해결
    • 최대 약 19GB 스왑과 12GB RAM 사용
    • 대형 서버(128코어, 512GB RAM)에서는 Fil-C 빌드 8분, musl 빌드 6분 소요

추가 라이브러리 및 애플리케이션 빌드

  • Fil-C에는 여러 라이브러리와 애플리케이션을 빌드하는 build_all_slow.sh 포함
  • 이를 병렬화한 build-parallel-20251023.py 스크립트 작성
    • 오류 발생 시 중단하지 않고 전체 빌드 진행
    • 병렬 빌드로 시간 단축 가능
  • phoenix 시스템에서 61개 타깃 중 60개 성공 (실시간 101분)
  • libcap만 빌드 실패 (liblto_plugin.so 로드 오류)
  • util-linux는 syscall 관련 수정 필요
  • 나머지 주요 패키지(attr, bash, curl, openssl, vim 등)는 문제 없이 빌드 완료

추가 테스트된 라이브러리 및 애플리케이션

  • boost 1.89.0: 대부분 정상 작동, 일부 vfork 관련 수정 필요
  • cdb-20251021: 정상 작동, 인위적 OOM 테스트에서 오류 메시지 차이
  • libcpucycles, libgc(gshim 대체), libntruprime, lpeg, luv 등 정상 빌드 및 테스트
  • mutt, tig, w3m 등 주요 CLI 애플리케이션도 정상 동작 확인

Debian 통합 (Filian)

  • Debian의 다중 아키텍처 구조를 활용해 Fil-C 전용 ABI(amd64fil0) 추가
    • 예: apt install bash:amd64fil0로 Fil-C 컴파일 버전 설치 가능
  • Fil-C는 /usr/include 대신 자체 디렉터리를 사용해 헤더 파일 경로 불일치 문제 발생
    • filian-install-compiler 스크립트에서 이를 Debian 표준 경로로 조정
  • Debian 빌드 도구(dpdk-buildpackage, sbuild 등)에 Fil-C 아키텍처 인식 추가
    • /usr/share/dpkg/cputable, config.sub 등 수정
  • Fil-C 및 표준 라이브러리를 /usr/libexec/fil/amd64 경로에 배치
    • filcc, fil++ 명령을 시스템 전역에서 사용 가능

Debian 패키지 빌드 예시

  • fillet 헬퍼 스크립트로 Debian 소스 패키지의 심볼 및 설치 경로 조정
  • tinycdb 패키지를 Fil-C로 빌드한 결과, amd64fil0 전용 .deb 패키지 3개 생성
    • 설치 후 nm, ldd 명령으로 Fil-C 심볼(pizlonated_) 및 라이브러리 경로 확인
    • 실행 시 Fil-C 런타임 보호 기능 작동 확인 (“memory safety” 위반 차단 메시지 출력)

추가 Debian 패키지 빌드

  • libc-dev: 의존성 해결용 가짜 패키지 생성
  • ncurses: Fil-C로 빌드 후 설치 가능
  • libmd: 아키텍처 간 버전 불일치로 재컴파일 필요
  • readline: 헤더 경로 심볼릭 링크 필요
  • lua5.4: readline 의존성 해결 후 정상 작동

결론

  • Fil-C는 메모리 안전성 강화와 기존 C/C++ 생태계 호환성을 동시에 달성하려는 시도
  • Debian 환경에서의 패키지 빌드 및 통합 가능성이 입증됨
  • 일부 빌드 스크립트와 헤더 경로 조정이 필요하지만, 대부분의 주요 오픈소스 패키지와 호환성 확보

함께 보면 좋은 글 β

▲
GN⁺ 6달전  [-]
Hacker News 의견
  • 링크된 벤치마크를 보면 Fil-C가 C보다 더 빠르게 보이는 경우가 있음
    아마 마이크로벤치마크의 변동성 때문일 거라 생각하지만, 일부 결과는 너무 빠르게 보여서 정확성 문제가 있는지 궁금해짐
  • 작성자가 Fil-C에 상당히 감명받아서 전체 Debian 시스템을 Fil-C로 재빌드하려는 시도를 하고 있음
    이를 위해 GC shim 라이브러리와 빌드 스크립트를 만들어 공유하고 있음
  • 서버에 swap이 12GB밖에 없어서 Fil-C 컴파일 중 메모리 부족으로 여러 번 재시작했음
    swap을 36GB로 늘리자 정상적으로 빌드되었고, 최대 19GB swap + 12GB RAM을 사용했음
    128코어, 512GB RAM 서버에서는 Fil-C 빌드에 8분, musl에 6분이 걸렸음
    Fil-C가 정적 분석을 많이 수행하는 듯함
    • 그건 LLVM+Clang 자체를 빌드하는 과정일 가능성이 높음
  • 새로 공개된 64비트 버전의 cdb가 엑사바이트급 데이터베이스를 지원한다는 점이 흥미로움
    cdb.cr.yp.to에서 확인 가능하며, 새 cdb 서브도메인이 pqconnect를 사용한다고 언급됨
    • 실제로는 cdb.cr.yp.to에 NS 레코드가 없어서 DNSCurve가 작동하는 구조임
      pqconnect는 HTTP(S) 연결 단계에서 사용되고, 둘 다 DNS에 공개키를 인코딩하지만 역할이 다름
      pqconnect는 CurveCP처럼 CNAME에 공개키를 포함함
    • RFC1034에 따르면 cdb.cr.yp.to는 cr.yp.to와 yp.to의 하위 도메인(subdomain) 으로 볼 수 있음
      다만 pq1 부분은 공개키가 아니라 서버의 장기 공개키 해시임
    • pqconnect 사용은 예전부터 있었지만, cdb.cr.yp.to의 CNAME은 10월 21일경 새로 추가된 것으로 보임
      Fil-C 관련 노트는 3일 전에 제출되었음
      관련 스레드
    • 참고로 11일 전에도 관련 논의가 있었음
      이전 토론 링크
  • 멋진 프로젝트라고 생각함
    목표는 C/C++ 프로그램 대부분이 Rust로 다시 작성할 필요 없이 안전하게 실행되도록 하는 것 같음
    Epic Games가 어떻게 관련되는지도 궁금함
    • Fil-C는 가비지 컬렉션 기반 언어라서 C보다 훨씬 느림
      새로운 코드를 작성하기보다는 WASM 샌드박싱처럼 기존 코드를 안전하게 감싸는 용도로 적합함
      다만 Fil-C는 크래시를 더 정확히 잡아냄
  • Phil의 작업이 드디어 정당한 인정을 받는 것 같아 기쁨
    Rust의 unsafe 모드에도 참고할 만한 점이 있을 듯함
    특히 Fil-C로 컴파일된 의존성을 정적 링크하는 방식은 흥미로움
    • 하지만 Fil-C는 현재 FFI를 지원하지 않음
      포인터 추적을 위해 프로그램 전체를 Fil-C가 통제해야 하므로 FFI는 구조적으로 맞지 않음
  • Fil-C 관련 주요 스레드들을 정리함
    예: Fil-C: A memory-safe C implementation,
    Safepoints and Fil-C,
    Fil’s Unbelievable Garbage Collector 등
    2024~2025년 사이의 메모리 안전성 논의가 이어지고 있음
  • Fil-C가 무엇인지 모르는 사람들을 위해 요약함
    Fil-C는 C/C++과 호환되는 메모리 안전 구현체로, 대부분의 코드가 거의 수정 없이 컴파일됨
    모든 메모리 오류는 panic으로 감지되며, 동시 GC와 InvisiCaps로 안전성을 확보함
    공식 사이트에서 자세한 설명을 볼 수 있음
    • Fil-C를 사용하려면 런타임에 Garbage Collector를 수용해야 함
  • build_all_fast_glibc.sh 스크립트가 31GB 메모리를 요구한다는 점이 놀라움
    이유를 알고 싶고, 직접 Fil-C를 시도해보고 싶음
    • 그건 LLVM 빌드와 링크 과정이 무겁기 때문임
  • 유명한 암호학자가 bash와 curl을 사용하는 모습이 흥미로움
    • 사실 curl | bash는 괜찮은 경우도 많음
      관련 글
답변달기