Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby

이 논문은 C 언어의 정의되지 않은 동작에 대한 기존 가정이 CHERI 의 엄격한 메모리 안전 모델과 충돌하여 가상 머신 (VM) 구현에 발생하는 함정을 CRuby 포팅 사례를 통해 분석하고, 이를 해결하기 위한 우회 방법과 그 영향을 제시합니다.

핵심

1. 배경: 왜 이 일을 했을까요?

• 기존 상황: 컴퓨터 프로그램은 늘 해커들의 공격 대상입니다. 특히 메모리 (데이터 저장소) 를 잘못 건드리면 큰 사고가 나죠.
• 새로운 해결책 (CHERI): 연구진들은 "기존의 주소 (집 번호) 대신, **복제 불가능한 허가증 (Capability)**을 주고, 그 허가증에 '이곳까지만 들어갈 수 있음'이라는 제한을 걸자"는 아이디어를 개발했습니다. 이를 CHERI라고 부릅니다.
• 문제점: 이 새로운 금고 (CHERI) 는 보안은 완벽하지만, 기존에 "임의대로 마음대로 다닐 수 있었다"고 생각했던 구식 프로그램 (CRuby) 들은 여기서 바로 멈춰버립니다. 마치 "집 번호만 있으면 어디든 갈 수 있다"고 믿던 사람이, "이 건물 3 층까지만 갈 수 있는 허가증이 있어야 한다"는 새 규정을 만나서 당황하는 상황과 비슷합니다.

2. 핵심 내용: CRuby 를 옮기며 발견한 '함정' 6 가지

연구진은 CRuby 를 CHERI 금고로 옮기려다 여러 가지 엉뚱한 이유로 막히는 상황을 발견했습니다. 이를 6 가지 유형으로 정리했습니다.

① "잘못된 길로 들어선 나침반" (Invalid Derived Pointer)

• 상황: CRuby 는 메모리 검사 (가비지 컬렉션) 를 할 때, 스택 (데이터 더미) 의 끝을 찾기 위해 한 변수의 주소를 가져와서 다른 변수의 주소를 유추합니다.
• 문제: 기존에는 주소가 숫자일 뿐이라 "이 숫자에 1 을 더하면 옆집 주소"라고 생각했지만, CHERI 에서는 **허가증의 범위 (Bounds)**가 정해져 있습니다. A 집 허가증으로 B 집 문을 열려고 하면, "범위를 벗어났다!"며 경보가 울립니다.
• 해결: 처음부터 "전체 건물을 다 다닐 수 있는 마스터 키 (Super Capability)"를 들고 다니면서, 그걸로 작은 열쇠를 만들어 쓰게 했습니다.

② "가짜 열쇠를 진짜로 착각한 것" (Dereferencing Ambiguous Pointers)

• 상황: CRuby 는 메모리 위에 있는 숫자 중 "어떤 게 주소처럼 생겼나?"를 보고, "아, 이건 주소겠지?"라고 추측해서 열어봅니다. (보안보다는 편의를 위한 방식)
• 문제: CHERI 에서는 숫자가 주소처럼 생겼다고 해서 **유효한 허가증 (Tag)**이 있는 건 아닙니다. 가짜 열쇠로 문을 열려고 하면 기계가 "이건 허위 열쇠다!"라고 바로 차단합니다.
• 해결: "생김새"만 보고 열지 말고, **허가증에 찍힌 도장 (유효성 태그)**을 먼저 확인하게 했습니다. 오히려 더 정확해져서 불필요한 작업을 줄일 수 있게 되었습니다.

③ "자리 넓히기 실패" (In-Place Reallocation)

• 상황: 프로그램이 메모리 공간을 더 많이 필요로 할 때, 기존 공간을 그대로 넓히려고 합니다. (예: 100 평짜리 방을 150 평으로 확장)
• 문제: 기존에는 "방이 넓어졌으니 같은 열쇠로 계속 쓰면 되지"라고 생각했습니다. 하지만 CHERI 에서는 방이 넓어지면 새로운 허가증이 발급되어야 합니다. 옛날 열쇠로는 새로 확장된 공간에 들어갈 수 없습니다.
• 해결: "방이 넓어지면 무조건 새 허가증 (포인터) 을 받아서 모든 곳에 업데이트하자"고 규칙을 바꿨습니다.

④ "빈 공간에 물건을 채우는 실수" (Using Padding Bits)

• 상황: 프로그래머들은 숫자 (정수) 의 모든 비트 (0 과 1) 를 다 쓸 수 있다고 믿고, 그 안에 작은 정보들을 꾹꾹 눌러 담습니다.
• 문제: CHERI 의 숫자 (허가증) 는 윗부분에 **비어있는 공간 (패딩 비트)**이 있습니다. 이 빈 공간에 정보를 넣으려 하거나, 그 빈 공간을 계산에 쓰면 엉뚱한 결과가 나옵니다.
• 해결: "비어있는 공간이 없는 정확한 크기의 숫자 (uint64_t)"만 쓰도록 했습니다.

⑤ "봉인된 문을 뚫으려다 걸린 것" (Modifying Temporary Capabilities)

• 상황: 프로그램이 계산할 때, 임시로 허가증을 만들어서 숫자만 건드리려 합니다.
• 문제: CHERI 에서는 **봉인된 허가증 (Sealed Capability, 예: 돌아갈 주소)**은 절대 건드리면 안 됩니다. 계산 과정에서 임시로 허가증을 만들려고 하면, "이건 봉인된 거야! 건드리면 안 돼!"라고 경보가 울립니다.
• 해결: 계산할 때는 허가증을 일반 숫자로 바꿔서 계산하고, 다시 필요할 때만 허가증으로 만들게 했습니다.

⑥ "다른 언어로 말하기" (Pointer Arithmetic on Non-Capability Type)

• 상황: 주소를 계산할 때, 허가증 (Capability) 이 아닌 일반 숫자 (size_t 등) 로 변환해서 계산합니다.
• 문제: 일반 숫자로 계산하면, 다시 허가증으로 돌아갈 때 범위 정보가 사라져 무효한 열쇠가 됩니다.
• 해결: 계산할 때도 반드시 **허가증 (uintptr_t)**을 사용하도록 했습니다.

3. 결과: 얼마나 느려졌나요?

• 연구진은 이 모든 수고를 다 해서 CRuby 를 CHERI 위에서 실행시켰습니다.
• 성능: 원래 속도보다 약 98% 정도만 느려졌습니다. (거의 차이가 안 날 정도로 훌륭합니다!)
• 예외: 일부 특수한 기능 (파이버 등) 은 아키텍처 최적화 코드가 없어서 속도가 10 배나 느려지기도 했지만, 전체적으로는 매우 성공적인 결과였습니다.

4. 결론: 이 연구가 우리에게 주는 교훈

이 논문은 **"보안 하드웨어 (CHERI) 를 쓰려면, 프로그래머들이 '아마도 이렇게 되겠지'라고 추측했던 C 언어의 관습들을 버려야 한다"**는 것을 알려줍니다.

• 기존: "주소는 숫자니까 마음대로 계산해도 돼."
• 새로운 CHERI: "주소는 허가증이니까, 범위와 도장을 확인해야 해."

이 연구를 통해 앞으로 더 안전한 가상 머신 (VM) 을 만들 때, 어떤 함정을 피해야 하는지 명확한 가이드가 되었습니다. 마치 새로운 보안 규정이 있는 건물을 지을 때, "문은 열려있을 거야"라고 믿지 말고 "잠금장치를 확인하자"는 원칙을 세운 것과 같습니다.

기술 요약

논문 요약: CHERI 상의 VM 구현 시 함정: CRuby 포팅을 통한 교훈

이 논문은 메모리 안전성을 강화하기 위해 설계된 새로운 하드웨어 아키텍처인 CHERI(Capability Hardware Enhanced RISC Instructions) 에 가상 머신 (VM) 을 포팅할 때 발생하는 기술적 함정과 해결 방안을 제시합니다. 저자들은 CRuby(루비 인터프리터) 를 CHERI 로 포팅하는 사례 연구를 수행하고, 기존 VM 포팅 사례 (MicroPython, JavaScriptCore, Rust) 를 분석하여 VM 구현에 특화된 문제들을 체계화했습니다.

1. 문제 제기 (Problem)

CHERI 는 기존 포인터를 대신하여 권한과 경계를 가진 'capabilities(역량)'를 사용하여 메모리 안전성 (공간적, 시간적) 을 보장합니다. 그러나 VM 은 복잡한 C 언어로 구현된 경우가 많으며, 기존 아키텍처의 **정의되지 않은 동작 **(Undefined Behavior, UB)에 의존하는 구현 기법들이 많습니다.

• 핵심 문제: C 언어 표준에서 정의되지 않거나 구현 정의된 동작 (예: 정수와 포인터의 상호 변환, 메모리 재할당 시 포인터의 유효성, 비트 필드 사용 등) 은 기존 시스템에서는 작동하지만, CHERI 의 엄격한 메모리 안전 모델과 충돌하여 예기치 않은 실패 (Capability Fault) 를 초래합니다.
• 기존 연구의 한계: 기존 포팅 사례들은 전체 프로세스나 특정 언어 (Rust) 에 초점을 맞추었으며, VM 런타임 시스템에 특화된 구체적인 함정과 해결책을 체계적으로 다룬 연구는 부족했습니다.

2. 연구 방법론 (Methodology)

• **사례 연구 **(Case Study) CRuby(버전 3.4.1) 를 CHERI-RISC-V(순수 역량 모드, Purecap) 환경으로 포팅했습니다. JIT 컴파일러와 외부 함수 인터페이스 (FFI) 는 제외하고, 런타임 시스템과 인터프리터에 집중했습니다.
• 분석 및 분류: CRuby 포팅 과정에서 발견된 오류와 기존 사례 연구 (MicroPython, JavaScriptCore, Rust 포팅) 를 종합하여, CHERI VM 구현의 함정을 6 가지 주요 카테고리로 분류하고 분석했습니다.
• 실험 및 검증: 발견된 문제들에 대한 해결책 (Workaround) 을 적용하여 CRuby 포팅을 완료하고, 성능 저하가 발생하는지 벤치마크를 통해 검증했습니다.

3. 주요 발견 및 함정 분류 (Key Findings & Categories)

논문은 VM 구현에서 발생하는 6 가지 주요 함정 카테고리를 제시합니다.

1) 잘못된 파생 포인터 (Invalid Derived Pointer)

• 문제: VM 은 스택 스캐닝이나 메모리 블록 메타데이터 접근 시, 다른 목적의 포인터에서 새로운 포인터를 유도하는 경우가 많습니다. CHERI 에서는 포인터가 경계 (Bounds) 를 가지므로, 작은 범위를 가진 포인터에서 더 넓은 범위를 필요로 하는 포인터를 유도하면 경계 오류 (Bounds Fault) 가 발생합니다.
• 해결: 전체 메모리 영역 (예: 전체 스택) 을 커버할 수 있는 '슈퍼 역량 (Super Capability)'을 유지하고, 필요한 포인터는 이를 기반으로 유도해야 합니다.

2) 모호한 포인터 역참조 (Dereferencing Ambiguous Pointers)

• 문제: 보수적 가비지 컬렉션 (Conservative GC) 은 스택의 정수 값이 포인터처럼 보이면 이를 포인터로 간주하여 역참조합니다. CHERI 에서는 정수를 포인터로 변환해도 유효성 태그 (Validity Tag) 가 설정되지 않아 태그 오류 (Tag Fault) 가 발생합니다.
• 해결: 비트 패턴 검사 대신 **유효성 태그 **(Validity Tag)를 확인하여 실제 포인터인지 판별해야 합니다. 이는 오히려 불필요한 객체 마킹을 줄여 성능을 개선할 수도 있습니다.

3) 인-플레이스 재할당 (In-Place Reallocation)

• 문제: realloc 이 같은 주소를 반환하더라도 CHERI 에서는 경계가 변경될 수 있습니다. 기존 VM 구현은 재할당 성공 시 원래 포인터를 계속 사용하는 경우가 많으나, 이는 확장된 영역에 접근할 때 경계 오류를 유발합니다.
• 해결: 재할당 후 반환된 새로운 포인터를 모든 참조 위치에 업데이트해야 합니다. 더 근본적으로는 인-플레이스 재할당에 의존하지 않는 설계가 권장됩니다.

4) 정수 타입의 패딩 비트 사용 (Using Padding Bits of Integer Types)

• 문제: VM 은 비트맵이나 비트 필드를 위해 정수 타입의 모든 비트를 사용한다고 가정합니다. 그러나 CHERI 의 (u)intptr_t는 상위 64 비트가 메타데이터 (경계 등) 로 사용되므로, 하위 64 비트만 유효한 정수 값입니다. 시프트 연산 시 패딩 비트를 포함하면 결과가 무작위적이거나 정의되지 않습니다.
• 해결: 비트 연산에는 **정확한 너비의 정수 타입 **(예: uint64_t)을 사용하여 패딩 비트 문제를 피해야 합니다.

5) 컴파일러가 생성한 임시 역량 수정 (Modifying Temporary Capabilities)

• 문제: sealed 된 역량 (예: 반환 주소) 을 정수 연산에 사용하거나 비트 연산을 수행하면, 컴파일러가 임시 역량을 생성하려다 'Sealed Fault'가 발생합니다.
• 해결: 연산 전에 (u)intptr_t 를 일반 정수 타입 (uint64_t) 으로 캐스팅하여 임시 역량 생성을 방지해야 합니다.

6) 비-역량 타입에서의 포인터 산술 (Pointer Arithmetic on Non-Capability Type)

• 문제: C 의 관습에 따라 포인터를 size_t 같은 일반 정수로 변환하여 연산 후 다시 포인터로 변환하는 코드가 많습니다. CHERI 에서는 (u)intptr_t 가 아닌 타입으로 변환하면 역량이 손실되어 유효하지 않은 포인터가 됩니다.
• 해결: 포인터 산술 시 반드시 **(u)intptr_t**를 사용해야 합니다.

4. 결과 (Results)

• 포팅 성공: CRuby 포팅은 총 34,046 개의 테스트 케이스 중 29,609 개를 통과했습니다. 실패한 케이스 중 상당수는 libyaml 라이브러리 부재나 AST 테스트 하이스의 충돌 등 포팅과 무관한 원인이었습니다.
• 성능 평가: 894 개의 마이크로 벤치마크를 통해 성능을 측정했습니다.
  • 평균적으로 포팅된 CRuby 는 기존 CRuby 대비 0.982 배의 처리량 (Throughput) 을 보였습니다.
  • 대부분의 벤치마크에서 성능 차이가 거의 없었으나, Fiber(코루틴) 관련 작업은 x86 어셈블리 최적화 구현을 사용하지 않아 약 10 배 정도 성능이 저하되는 outliers 가 관찰되었습니다.
  • 적용된 해결책 (Workaround) 들은 대부분 성능 오버헤드를 거의 유발하지 않았습니다.

5. 의의 및 기여 (Significance & Contributions)

1. VM 포팅 가이드라인 제시: CHERI 환경에서 VM 을 개발하거나 포팅할 때 주의해야 할 구체적인 함정 6 가지를 분류하고, 각각에 대한 해결책과 그 영향을 명확히 제시했습니다.
2. C 언어 UB 의 위험성 재조명: C 언어의 정의되지 않은 동작이 CHERI 와 같은 엄격한 메모리 안전 아키텍처에서 어떻게 치명적인 오류로 이어지는지 구체적인 사례를 통해 입증했습니다.
3. 보안과 성능의 균형: 일부 해결책은 보안 약화나 오버헤드를 초래할 수 있으나, CHERI 의 유효성 태그를 활용한 정밀한 GC 구현 등 새로운 최적화 기회를 제공함을 보였습니다.
4. 미래 연구 방향: 이 연구는 CHERI 기반의 더 안전한 VM 구축을 위한 기초 지식을 제공하며, 향후 JIT 컴파일러 포팅 및 FFI 보안 강화 등 추가 연구의 발판이 됩니다.

결론적으로, 이 논문은 CHERI 와 같은 차세대 보안 아키텍처를 수용하기 위해서는 단순한 코드 수정을 넘어, VM 의 내부 구현 기법과 C 언어의 암묵적 가정을 근본적으로 재검토해야 함을 강조합니다.