Pixel 10 베이스밴드에 Rust를 통합한 메모리 안전 전략
Google Pixel 10 모뎀 펌웨어의 Rust 도입 사례를 바탕으로 베이스밴드 보안, DNS 파서 전환, FFI 통합과 임베디드 Rust 고려사항을 정리한다.
2026-08-14 · 최초 발행 2026-04-13
외부 입력을 처리하는 베이스밴드의 공격 표면
Google은 2026년 4월 Pixel 10 모뎀 펌웨어에 Rust를 도입한 사례를 공개했다. 셀룰러 베이스밴드는 LTE와 5G 같은 이동통신 프로토콜을 처리하는 저수준 소프트웨어이며, 수십 MB 규모의 실행 코드와 복잡한 프로토콜 스택을 포함한다.
이 영역은 네트워크에서 받은 데이터를 직접 해석한다. 그래서 파싱 과정의 결함은 원격 코드 실행으로 이어질 수 있는 공격 표면이 된다. Pixel 모뎀 DNS 파싱에서 발생한 메모리 안전 취약점인 CVE-2024-27227, 그리고 Pixel 모뎀에서 인터넷 기반 원격 코드 실행이 가능함을 보인 Project Zero 실증은 이 위험을 보여준다.
문제가 되는 유형은 버퍼 오버플로, Use-After-Free, 범위 초과 읽기(Out-of-Bounds Read)다.
Rust를 선택한 핵심 이유는 소유권 시스템과 빌림 검사기(Borrow Checker)가 메모리 오류를 컴파일 단계에서 막기 때문이다. 런타임 오버헤드 없이 안전성을 확보하면서, 제로 코스트 추상화(Zero-Cost Abstraction)로 C/C++ 수준의 실행 성능을 유지할 수 있다. STM32F4 마이크로컨트롤러 벤치마크에서는 C 대비 98.7% 성능을 달성했다.
전면 재작성 대신 위험한 파서부터 바꾸기
Google은 기존 C/C++ 펌웨어 전체를 다시 쓰지 않았다. 외부 데이터를 직접 받아 취약점이 발생하기 쉬운 DNS 파서를 첫 교체 대상으로 삼고, 이후 다른 프로토콜 파서로 범위를 넓히는 방식을 택했다.
이 접근은 FFI(Foreign Function Interface)를 통해 기존 C/C++ 코드와 공존할 수 있다는 Rust의 특성을 활용한다. 기존 데이터 구조는 유지하고, 파싱 로직만 Rust로 대체할 수 있다.
DNS 파서에는 hickory-proto를 사용했다. 이 라이브러리는 75% 이상 테스트 커버리지를 갖고 있으며 유지보수와 커뮤니티 채택이 활발하다. 베어메탈 환경에서 동작하도록 no_std 기능도 업스트림에 기여했다. C 측에는 int32_t process_dns_response(uint8_t*, int32_t) 형태의 단순한 인터페이스를 제공했다.
Pigweed 빌드와 Rust 런타임을 연결하는 방식
독립적인 cargo 빌드 대신, Rust를 기존 Pigweed 빌드 시스템에 직접 포함했다. 심볼 충돌을 피하고 대규모 코드베이스에서 확장하기 위한 선택이다.
Rust 크레이트는 .rlib로 컴파일한 뒤 extern crate 선언을 통해 하나의 staticlib로 링크한다. 이후 llvm-ar -x로 Rust staticlib에서 오브젝트 파일을 추출해 기존 링커에 넘긴다. 최종 모뎀 이미지에는 이 과정을 거친 Rust 코드가 포함된다.
| 항목 | 구현 방식 |
|---|---|
| 메모리 할당 | GlobalAlloc 트레이트로 기존 C 메모리 API에 연결 |
| 패닉 처리 | FFI 바인딩으로 Pigweed 크래시 핸들러 호출 |
| FFI 코드 생성 | bindgen으로 C++ 콜백 바인딩 자동 생성 |
| 심볼 충돌 해결 | compiler_builtins 약한 심볼을 링킹 전 제거 |
코드 크기와 의존성의 균형
DNS 파서 전환에 포함된 구성의 크기는 다음과 같다.
| 구성 요소 | 크기 |
|---|---|
| Rust 심 레이어(Shim Layer) | 4 KB |
| core, alloc, compiler_builtins | 17 KB |
| hickory-proto + 의존성 | 350 KB |
| 합계 | 371 KB |
hickory-proto는 임베디드 최적화를 목적으로 한 라이브러리는 아니다. 다만 모뎀 펌웨어에는 엄격한 메모리 제약이 없었기 때문에, 이 사례에서는 커뮤니티 지원과 코드 품질을 우선했다.
의존성 관리는 별도 과제다. hickory-proto 하나에서 30개 이상의 의존 크레이트가 발생하므로, 임베디드 환경에서는 의존성을 줄이는 전략이 필요하다. 범용 크레이트의 no_std 지원도 아직 제한적이어서 업스트림 기여를 통한 생태계 확장이 요구된다.
Android과 시스템 소프트웨어로 넓어진 Rust 적용
Google은 Android 전체에서 Rust 도입 뒤 메모리 안전 취약점이 크게 줄었다고 보고했다. C/C++ 코드의 메모리 안전 취약점 밀도는 백만 줄당 약 1,000건이고 Rust는 백만 줄당 약 0.2건으로, Rust 코드의 밀도는 C/C++ 대비 1,000배 감소했다. 메모리 안전 취약점은 2025년 기준 전체 취약점의 20% 미만으로 하락했으며, 절대 수치는 2019년 223건에서 2024년 50건 미만으로 줄었다.
개발 과정에서도 차이가 보고됐다.
| 지표 | Rust vs C++ |
|---|---|
| 롤백률(Rollback Rate) | Rust가 약 4배 낮음 |
| 코드 리뷰 시간 | Rust가 25% 적음 |
| 리비전 횟수 | Rust가 20% 적음 |
Android 플랫폼에는 약 500만 줄의 Rust 코드가 있으며, 신규 Rust 코드 양은 C++에 필적한다. Linux 커널은 6.12 버전부터 프로덕션 Rust 드라이버를 탑재했고, Chromium은 파서 영역에 Rust를 도입하고 있다. Nearby Presence, MLS(Message Layer Security), RCS 메시징 프로토콜도 보안 앱 적용 범위에 포함된다.
임베디드 팀이 검토할 전환 조건
Pixel 10은 모뎀 베이스밴드 DNS 파서를 Rust로 바꾼 최초의 Pixel 디바이스다. 자동차 분야에서는 Volvo XC90과 Polestar 3이 2025년 1월 ECU(Electronic Control Unit) 소프트웨어에 Rust를 적용했다. Linux의 Rust for Linux 프로젝트 역시 메모리 안전 드라이버를 프로덕션에 배포하기 시작했다.
실제 도입에서는 언어만 결정해서는 충분하지 않다. GN, Bazel, Make 같은 기존 빌드 시스템과 Rust 툴체인을 연결해야 하며, cargo-gnaw, gn-rs 같은 브리지 도구를 활용할 수 있다. Rust 임베디드 경험자는 부족하므로 기존 C/C++ 팀의 전환 교육도 필요하다.
| 항목 | C/C++ | Rust |
|---|---|---|
| 메모리 관리 | 수동(malloc/free) | 소유권 시스템 자동 관리 |
| 버퍼 경계 검사 | 개발자 책임 | 컴파일러 강제 |
| Null 포인터 | 허용(런타임 크래시) | Option 타입으로 컴파일 타임 처리 |
| 동시성 안전 | 개발자 책임(데이터 레이스 가능) | Send/Sync 트레이트로 컴파일 타임 보장 |
| Use-After-Free | 발생 가능 | 빌림 검사기가 원천 차단 |
| 성능 | 최적 | C/C++ 대비 동등(98.7%) |
| 기존 코드 연동 | 해당 없음 | FFI로 C/C++ 호출 가능 |
Pixel 10 사례는 기존 펌웨어의 고위험 파서를 모듈 단위로 교체할 수 있음을 보여준다. 371 KB 규모로 DNS 파서를 통합하면서 기존 시스템과의 호환성을 유지했고, Android에서 축적된 취약점 밀도와 개발 지표는 메모리 안전 언어 전환의 근거가 된다.
Sources
- Bringing Rust to the Pixel Baseband - Google Security Blog
- Rust in Android: move fast and fix things - Google Security Blog
- Rust Adoption Drives Android Memory Safety Bugs Below 20%
- Deploying Rust in Existing Firmware Codebases - Google Security Blog
- Google Pushes Rust in Legacy Firmware - SecurityWeek
- Rust for Embedded Systems: Current State and Open Problems
- Eliminating Memory Safety Vulnerabilities at the Source - Google Security Blog