GrapheneOS가 ARM MTE로 발견한 블루투스 메모리 손상

 (grapheneos.social/@GrapheneOS)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Pixel 8·Pixel 8 Pro의 하드웨어 메모리 태깅 지원이 Android 14 QPR2에서 Bluetooth LE에 새로 들어간 메모리 손상 버그를 드러냄
  • 원인은 Bluetooth LE의 upstream use-after-free 버그로 확인됐고, GrapheneOS는 수정 패치를 만들어 새 릴리스에 포함할 예정임
  • Samsung Galaxy Buds2 Pro의 Bluetooth LE 모드에서 문제를 재현한 사용자가 수정 동작을 확인했으며, stock Pixel OS도 영향을 받음
  • GrapheneOS는 Bluetooth가 큰 공격 표면인 만큼, 해당 프로세스의 메모리 태깅을 끄는 우회책은 단기적으로도 부적절하다고 봄
  • Android Bluetooth 코드 일부는 Rust로 이식됐지만, 남은 코드 이식과 HWASan·MTE 빌드의 실제 기기 테스트가 더 필요함

Android 14 QPR2의 Bluetooth LE 버그와 수정

  • GrapheneOS는 Pixel 8 및 Pixel 8 Pro의 하드웨어 메모리 태깅 지원으로 Android 14 QPR2의 Bluetooth LE 메모리 손상 버그를 발견함
    • 모든 Bluetooth 기기에서 발생하는 문제는 아니며, 특정 Bluetooth LE 기기에서만 재현됨
    • GrapheneOS는 새로 도입된 기능을 수정하거나 임시로 비활성화하는 방법을 조사 중임
  • 원인은 Bluetooth LE의 upstream use-after-free 버그로 확인됐고, GrapheneOS는 패치를 개발함
    • 우선순위는 해당 수정이 들어간 GrapheneOS 릴리스를 빠르게 배포하는 것임
    • Android 보안 버그로 보고할 예정임
    • 이 수정은 BLE 오디오 회귀도 해결할 것으로 보임
  • Samsung Galaxy Buds2 Pro를 Bluetooth LE 모드로 사용해 문제를 재현하던 사용자가 수정이 동작함을 확인함
  • 같은 문제는 stock Pixel OS에도 영향을 줌
  • GrapheneOS는 hardened_malloc의 메모리 태깅 지원으로 이를 감지했고, 복사 가능한 리포트를 담은 MTE 크래시 알림을 추가함

MTE 적용 방식과 Android Bluetooth 코드의 과제

  • GrapheneOS는 이 프로세스에서 메모리 태깅을 끄는 우회책을 단기적으로도 적절하지 않다고 봄
    • Bluetooth는 해당 버그의 실제 악용 가능성과 별개로 큰 공격 표면임
  • Android는 Bluetooth 코드 상당 부분을 Rust로 이식했지만, 남은 코드 이식에도 더 많은 자원이 필요함
  • 실제 환경에서는 다양한 Bluetooth 기기를 대상으로 HWASan 및 MTE 빌드 테스트가 더 필요함
  • Pixel 기기는 큰 하드웨어 보안 기능인 MTE를 탑재했지만, 기본 OS는 3.125% 메모리·캐시 사용량 절감을 이유로 활성화하지 않음
    • 계산은 태그된 메모리 16바이트당 4비트 태그에 기반함
    • heap MTE는 비동기 모드(async mode)에서 성능 오버헤드가 거의 0%에 가깝고, asymmetric mode에서는 SSP 같은 기존 완화책보다 비용이 낮음
  • GrapheneOS는 기본 OS와 호환성이 알려진 사용자 설치 앱에 MTE를 기본 활성화함
    • Settings > Security에서 모든 사용자 설치 앱에 대해 opt-in으로 켤 수 있음
    • 크래시 리포트를 복사할 수 있는 알림과 앱별 토글을 제공함
  • GrapheneOS의 hardened_malloc MTE 구현은 표준 랜덤 태그와 전용 free 태그를 사용하며, 이전 태그와 현재 또는 이전 인접 태그를 동적으로 제외함
  • Chromium 통합은 수정됐고, PartitionAlloc도 개선할 예정임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Pixels가 MTE라는 대형 하드웨어 보안 기능을 탑재해 놓고도 OS에서는 메모리/캐시 사용량 3.125% 를 아끼려고 켜지 않는다는 건 이상함
    Pixel 팀에서 이 결정을 어떻게 정당화하는지 정말 보고 싶고, 미미한 성능 이득 때문에 이렇게 중요한 보안 기능을 끄는 사고 과정이 궁금함

    • AOSP 엔지니어인데, Bluetooth 쪽을 맡고 있지는 않아 이 사안의 깊은 내용은 모름
      다만 GrapheneOS는 멋진 프로젝트이지만 지원 기기가 대략 11종뿐이고, AOSP 변경은 훨씬 큰 OEM 생태계를 고려해야 함
      Android를 더 좋게 만들 방법은 늘 찾고 있지만, 특정 기능 출시를 비판하면서 더 큰 OEM 생태계를 무시하는 건 시야가 좁아 보임
      이 기능이 켜지지 않은 이유가 메모리/캐시 3% 때문일 가능성은 매우 낮고, 다른 고려사항이 있었을 것 같음
    • 절충점은 메모리 사용량이나 성능만이 아니라, 이전에는 없던 사용자에게 보이는 크래시도 포함됨
      기능을 켤지 말지 결정할 때는 아마 이쪽이 더 큰 요인일 가능성이 큼
    • 3% 메모리 사용량을 아끼려고 결정했다는 비난은 너무 단정적인 것 같음
      다른 OS도 현재 MTE 활성화 상태로 출시하지 않는다고 하니, 켤지 말지는 더 미묘한 판단일 가능성이 큼
    • 요약하면, 이 기능을 안 쓰고 있다거나 3.125% 메모리/캐시 사용량 때문이라고 가정하지는 않겠음
      Google 쪽 사람들이 애초에 하드웨어 MTE를 밀어붙였고, ASAN, syzkaller 등에 관여한 팀에서 시작했음
      Android 팀 소속은 아니었지만 Android 쪽 도움과 지원이 있었고, ARM 등과의 협력도 당연히 있었음
      당시 그 팀들을 이끌던 입장이라 절충점을 잘 아는데, 메모리나 캐시 문제만 있는 게 아님
      MTE는 동적으로 켜고 끌 수 있고 성능 비용이 거의 0에 가깝도록 설계된 건 맞지만, 당시 주된 사용처는 표본 추출 기반 버그 찾기였음
      전체 기기군에서 1% 시간만 켜도 충분히 큰 규모라면 버그를 매우 빠르게 찾을 수 있고, 내부 테스트에도 쓸 수 있음
      즉 원할 때 ASAN에 준하는 기능을 켰다 끌 수 있게 만드는 것이 목표였음
      항상 켜 둔 보안 완화책으로 쓰는 것은 부차적인 가능성이었고, 메모리 오버헤드 외에도 문제가 있음
      예를 들어 사용자에게 보이는 크래시가 갑자기 많이 생기는데, MTE가 있는 폰에서는 크래시가 나고 없는 폰에서는 안 날 수 있어 일관성도 없음
      개발자 입장에서도 MTE 활성화 폰이 거의 하나뿐인 상황에서 모두에게 그 폰으로 테스트하라고 강제해야 하니 반갑지 않을 것임
      보안 익스플로잇을 막을 수는 있고, 악용 대신 크래시가 나게 만들 수 있음
      무해한 버그도 잡을 수 있음
      하지만 앞서 말했듯 안 쓴다고 가정하지는 않겠고, 프로덕션에서 항상 켜 두지는 않는다고 보는 편이 맞아 보임
      이런 하드웨어 기능 도입 경험이 있는 사람이라면, 시스템이 부팅되고 실행되며 특정 동작에서만 MTE 아래 크래시가 난다는 사실 자체가 오히려 이미 쓰고 있다는 좋은 신호라고 할 것임
      안 쓰고 있었다면 아마 백만 번은 크래시가 났을 것임
      덧붙이면, 런타임 완화책으로서 최선인지도 명확하지 않음

  • 기본 Pixel은 최종 사용자에게 기본 활성화 상태로 제공하지 않을 수 있지만, 원하면 누구나 개발자 옵션에서 Memory Tagging Extensions를 켤 수 있음
    끌 때까지 유지하거나, 특정 앱 테스트용으로 한 세션만 켤 수도 있음

    • 그건 GrapheneOS에서 쓰는 것과 같지 않고, Bluetooth의 상당 부분도 제외됨
      기본 Pixel OS에서 개발자 옵션으로 메모리 태깅 지원을 켜는 건 사용 가능 상태로 만들 뿐 실제로 쓰지는 않음
      Android Debug Bridge(ADB) 셸에서 setprop으로 힙 메모리 태깅도 켜야 함
      할당에 태그를 붙이지 않으면 단순히 켜져 있어도 아무 가치가 없음
      기본 할당자 구현인 Scudo를 통해 기본 OS에서 사용자 공간 힙 MTE를 완전히 켤 수는 있지만, 현재는 특별히 강화된 구현은 아님
      MTE 백엔드를 쓰는 KASan도 setprop으로 사용할 수 있지만, 지금은 강화 용도로 설계되지 않았고 앞으로도 그럴지 명확하지 않음
      커널에는 KASan 일부가 아닌 별도 MTE 구현이 필요할 가능성이 높고, GrapheneOS도 아직 하지 않았으므로 현재 MTE 강화는 사용자 공간 기능임
      GrapheneOS는 hardened_malloc을 위해 자체 하드웨어 메모리 태깅 구현을 쓰며, 보안 속성이 더 강함
      기본 OS에 기본 활성화하려면 이 이슈를 포함한 여러 문제를 고치거나 우회해야 했음
      메인 코어에 비동기 MTE를 쓰는 대신 모든 코어에서 비대칭 모드를 사용함
      비대칭 모드는 쓰기에는 비동기, 읽기에는 동기식이라 익스플로잇 성공 기회의 창을 남기지 않고 제대로 차단함
      시스템 호출에서 검사되며, 또 다른 우회 경로가 될 수 있는 io_uring은 SELinux 제한으로 Android에서 핵심 시스템 프로세스 2개에만 허용됨
      fastbootd는 설치 중에만 쓰이고, snapuserd는 업데이트 적용 후 핵심 OS에서 사용됨
      GrapheneOS는 기본 OS와 호환성이 확인된 앱에 항상 힙 MTE를 사용함
      사용자 설치 앱 중 호환성 데이터베이스에 없고 스스로 호환 표시를 하지 않은 앱에는 앱별 MTE 토글을 제공함
      사용자는 사용자 설치 앱에 기본적으로 MTE를 강제하도록 켤 수도 있고, 호환되지 않는 앱만 제외할 수도 있음
      이를 실제로 쓸 수 있게 하려면 사용자에게 보이는 크래시 보고 시스템이 필요했고, 개발자에게 유용한 크래시 보고서를 쉽게 복사해 보낼 수 있게 구현했음
    • Pixel 7a에서 개발자 옵션 메뉴를 세 번 찾아봤는데 찾을 수 없었음
      설정에서 Memory Tagging Extensions를 검색하면 있다고 나오는데, 어딘가 숨겨진 건가 했더니 Pixel 8 폰 전용이었음: https://news.ycombinator.com/item?id=38125379

  • GrapheneOS는 보안 측면에서 다른 것들보다 너무 앞서 있어서 Pixel 하드웨어 말고 다른 걸 고르는 게 의문스러워짐
    하지만 정말 교체식 배터리를 원함
    요즘은 왜 모든 게 이렇게 별로인지 모르겠음

    • 현재 Pixel만 우리 보안 요구사항을 충족함
      다른 Android 기기는 근처에도 못 옴
      하드웨어 메모리 태깅 지원은 Pixel의 여러 큰 보안 장점 중 하나임
      공식 하드웨어 요구사항 목록은 여기 있음: https://grapheneos.org/faq#future-devices
      이 요구사항은 8세대 Pixel에서 완전히 충족됨
      6/7세대 Pixel은 MTE, BTI, PAC만 빠져 있는데, MTE가 하드웨어 요구사항 목록에서 가장 가치 있는 기능임
      제대로 된 보안 패치가 더 중요하고, Pixel 밖에서는 같은 방식으로 제공되지 않음
      Android에는 월간, 분기, 연간 릴리스가 있음
      다른 Android OEM은 월간 보안 백포트 중 Critical/High 심각도 수정만 모두 제공하고, 대부분의 개인정보 보호 수정을 포함한 Moderate/Low 심각도 수정은 대부분 제공하지 않음
      대체 OS를 써서 이런 패치를 제공하면 일부 완화되지만, 해당 기기용 대체 OS는 여러 방식으로 보안을 되돌리는 경우가 많음
      펌웨어와 많은 기기 지원 코드는 실제로 OEM에서 옴
      Android 12 커널/드라이버 위에 Android 14 QPR2를 올려 실행하는 건 가능하지만, OS의 큰 부분에 대한 보안 개선이 빠지게 됨
      Pixel 배터리는 기기를 손상시키지 않고 교체하기가 간단하지는 않지만, 공식 지원되고 공식 부품도 있음: https://www.ifixit.com/Device/Google_Pixel
      기본도 갖추지 못한 안전하지 않은 기기를 지원할 수는 없음
      우리 하드웨어 요구사항 목록에는 대부분 Android OEM이 제공하지 않는 매우 기본적인 것들과, 이제 적절한 보안의 기본 요구사항으로 보는 MTE 같은 고급 기능이 함께 들어 있음
      다른 기기도 지원하고 싶지만, 그 기기들이 이 요구사항을 충족해야 함
      메모리 태깅은 표준 Cortex ARMv9 코어가 지원하는 기본 기능임
      Qualcomm이 이를 구현하지 않고, 이를 지원하는 SoC를 쓰는 OEM들도 설정을 하지 않는 건 아쉬움
      CPU 아키텍처에는 기능이 있는데 SoC나 OEM 때문에 사용할 수 없는 건 슬픈 일임
    • GrapheneOS는 아니지만 꽤 가까운 CalyxOS가 Fairphone 5 지원을 시작했고, 알기로는 교체식 배터리가 있음: https://calyxos.org/news/2024/03/05/fp5/
    • 동의하지만, 구형 Pixel 기기 지원을 매우 빨리 끊는 편이라 꽤 성가심
      그래도 Pixel 8은 7년 지원 예정이라 다행임
    • 폰에 아주 비싼 비밀을 담고 있다면 결국 Google에 굴복하게 됨
      Apple도, Samsung도 믿기 어렵고 Google이 그나마 최고가 됐음
    • Pixel은 응급 서비스와 관련해 오래된 문제가 있어 보임: https://www.reddit.com/r/GooglePixel/search/?q=emergency

  • GrapheneOS를 쓰는 사람이 답해주면 좋겠음

    1. 설치가 많이 어려운가? 특수 케이블이 필요하고 Android 기기 탈옥 지식이 많이 필요함, 아니면 그냥 안내를 따라가면 충분함?
    2. 일상용으로 쓰기 매우 불편한가? 폰이 얼마나 자주 크래시 나고 며칠씩 디버깅해야 함? 은행 앱은 동작함?
    • 설치는 쉽고, 99% 사용 사례에서는 다른 Android 폰만큼 편리함
      다만 최근 아내와 Orlando, Florida로 Disney World와 Universal Studios에 갔을 때, 샌드박스된 Google Play Services로 앱들이 대체로 동작하긴 했지만 성가신 문제가 있었음
      My Disney Experience 앱은 위치 관련 오류가 꽤 있었고, 간헐적으로 중요한 작업을 하려면 미국이나 캐나다에 있어야 한다고 떠서 아내 폰을 우회책으로 써야 했음
      Universal 앱에서는 계정 로그인을 할 수 없었는데, 아내의 기본 Samsung Galaxy에서는 잘 돼서 GrapheneOS 문제로 보였음
      또 Google Wallet으로 신용카드 결제를 한다면 Google이 GrapheneOS를 인증하지 않기 때문에 지원되지 않음
      Wallet의 다른 기능은 동작함
      Uber는 문제없이 동작함
      그 외에는 독점 앱을 쓰지 않음
      주로 자유/오픈소스 앱을 쓸 생각이라면 문제가 없을 것임
      대부분의 독점 앱은 샌드박스된 Google Play Services로 동작하지만, 그중 업무상 매우 중요한 앱이 있다면 Universal Studio와 My Disney Experience에서 겪은 것처럼 성가신 문제를 만날 수 있음
      1. 아니오, 매우 쉬웠음
        일반 USB 케이블과 Linux 명령줄의 adb를 썼지만, 권장 방법은 Chromium의 WebUSB를 쓰는 방식이고 비기술자에게 더 쉬워야 함
        다만 내 경우엔 그게 잘 안 됐음
      2. 아니오, 매우 편리함
        샌드박스된 Google Play Services가 있어서, 현대 생활을 견디게 해주는 온갖 독점 앱을 설치할 수 있으면서도 Google Play가 폰 전체에 무제한 접근하지는 못한다는 점에서 양쪽 장점을 잘 취함
        더 격리하고 싶으면 별도 사용자를 만들고 Google Play 관련 항목을 그 계정에서 실행할 수 있음
        잠깐 해봤지만 개인적으로는 매번 사용자 전환하기가 귀찮았음
        폰은 한 번도 크래시 난 적이 없고, 은행 앱도 동작함
        기기는 Pixel 6a임
    • 웹 설치기로 설치하면 매우 쉬움: https://grapheneos.org/install/web
      설치된 기기를 살 수도 있지만, 거의 누구나 웹 설치기를 쓸 수 있음
      Android, ChromeOS, macOS에서는 특히 쉽고, Windows는 드라이버 설치가 필요해 조금 더 까다로움
      데스크톱 Linux는 udev 규칙 설치가 필요하고, 소프트웨어 버전이 고정된 일부 배포판은 방해가 되는 버그 있는 서비스가 있음
      비기술자도 할 수 있고 WebUSB를 지원하는 브라우저만 있으면 됨
      특별한 소프트웨어는 필요 없음
      일상용으로는 샌드박스된 Google Play를 쓰면 기본 Pixel OS와 거의 같고 앱 호환성도 거의 비슷함
      크래시는 유의미하게 더 많이 겪지 않을 가능성이 큼
      기본 OS에는 없는 사용자 대상 크래시 보고가 있어서 원래는 몰랐을 크래시를 알아차릴 수는 있음
      메모리 손상이 있는 버그 많은 앱은 앱별 호환 모드를 켤 때까지 크래시 날 수 있고, 특히 사용자 설치 앱 전체에 MTE를 강제하도록 선택하면 그럴 가능성이 큼
      은행 앱은 은행이 Google 인증이 아닌 OS를 허용한다면 동작하고, 아직은 대부분 허용함
      다만 은행들이 점차 Google 인증이 아닌 OS를 막고 있어서, 이는 본질적으로 반경쟁 규제 이슈로 다뤄져야 함
      그동안 은행들이 https://grapheneos.org/articles/attestation-compatibility-guide를 쓰도록 설득하는 중임
    • 일상용으로 못 쓸 정도는 아니지만 가장 편한 선택도 아님
      보안 추가 기능, 샌드박싱 설정, hardened memory allocator 때문에 약간 느린 점은 그냥 순정 Android를 쓰며 데이터 접근 요청에 전부 OK 누르는 것보다 번거로움
      초기 설정과 GrapheneOS가 무엇이 다른지, 보안 기능을 어떻게 쓰는지 이해하는 데도 시간이 조금 걸림
      4년 쓰는 동안 크래시는 없었음
      적어도 시스템 전체 크래시는 없었고, 며칠씩 디버깅해야 하는 크래시는 Pixel 하드웨어와 소프트웨어가 서로 잘 맞춰져 있어 경험상 생기지 않음
      은행 앱은 앱에 따라 다름
      어떤 앱은 Play Services 없이도 동작하고, 대부분은 샌드박스된 Play Services로 동작하며, 아주 일부만 전혀 동작하지 않음
      어떤 은행을 쓰는지 말하면 다른 사용자가 동작 여부를 확인해줄 수 있음
    • 설치는 극도로 쉬움
      어려운 설치 방식도 폰을 USB로 연결하고 전원/볼륨 버튼을 조금 누른 뒤 터미널 명령 두세 개를 복사해 붙여 넣는 정도임
      쉬운 방식은 폰을 컴퓨터에 연결하고 Chrome 브라우저에서 동작하는 원클릭 설치 버튼을 누르는 것뿐임
      Google Pixel 6가 나온 직후부터 거의 계속 일상용 OS로 써 왔고, 단 한 번도 크래시가 난 적 없음
      버그가 나거나 디버그, 수정, 유지보수가 필요했던 적도 없음
      시도한 모든 앱이 순정 Android처럼 그냥 동작했고, 솔직히 차이를 거의 못 느낌
      가끔은 이게 원래 폰에 깔려 있던 OS가 아니라는 사실도 잊음
      개인적으로 은행 앱 Discover는 동작하지만 다른 앱은 확실히 모르겠음
      그래도 Google Play services가 있고 설치 후 부트로더가 잠기므로 아마 대부분 동작할 것 같음

  • 2024년이면 seL4 정신을 잇되 더 엄격한 수준의 형식 검증된 운영체제, 애플리케이션, 도구가 필요함
    요즘 같은 시대에 가볍게 테스트된 과설계 코드베이스와 취약하고 위험한 언어를 이어 붙이는 건, 외국 행위자가 해킹해 사용자가 죽을 수도 있고, 많은 성가신 버그와 악성코드·해킹 공격 표면을 만드는 일임
    그 위에 깔끔하고 통합된 사용자 경험과 쓸 만한 기능도 제공해야 하며, 그렇지 않으면 엔지니어링은 모두 헛수고가 됨

    • 경험상 구획화가 훨씬 강한 보안 수단임
      Qubes OS를 보면 됨

  • 괜찮은 싱글 보드 컴퓨터 중 Arm MTE를 구현한 게 있나? 최신 Raspberry Pi 같은 것 말임

    • 아마 없을 것 같음
      RasPi 5는 쿼드 A76이고 v8.2 확장을 쓰는데, MTE는 v8.5임

  • MTE는 CHERI와 비교하면 어떤가?

    • CHERI는 실제 하드웨어 강제 보호를 제공함
      MTE는 잠재적 보안 버그를 찾기 위한 것이고, 진짜 보호는 아님
      태그가 4비트뿐이고 애플리케이션이 위조할 수 있어서, 공격자가 올바른 태그를 맞춰야 한다면 무작위로 골라도 1/16 확률로 맞음
      MTE를 적용하면 공격자가 아니어도 가끔 잘못된 접근이 발생하고, 실제로 나쁜 결과를 만들지 않는 경우를 잡아낼 수 있다는 발상임
      전형적인 버퍼 오버플로를 생각하면, 버퍼 끝 바로 뒤 단어들이 다른 용도로 쓰이지 않아 실제로는 동작할 수도 있음
      MTE는 이런 접근을 감지하고, 무기화된 익스플로잇이 되기 전에 조사하고 패치할 수 있게 해줌
    • MTE와 CHERI는 비슷한 접근을 쓰지만, MTE는 일반적인 경우 강한 보안을 제공하기에는 태그가 충분히 크지 않음
      다만 예약 태그를 통해 강한 결정적 보안 속성을 제공할 수 있음
      태그되지 않은 것은 0 태그이고, 태그된 것은 기본 제외 때문에 기본적으로 0이 아닌 태그를 가짐
      다른 태그도 명령어로 정적·동적으로 제외할 수 있지만, 해제된 메모리 같은 내부 용도로 0 태그를 쓰면 어떤 태그된 포인터도 접근할 수 없다는 사실을 이용할 수 있음
      hardened_malloc에서는 할당 슬롯에 대해 인접 태그와 이전에 사용한 태그를 동적으로 제외함
      이로써 선형 오버플로와 작은 오버플로에 대해 결정적 보호를 제공함
      use-after-free의 경우, 해제된 할당을 가리키는 포인터는 해제된 동안이나 다시 할당된 직후에는 접근할 수 없고, 다음에 다시 배정될 때까지 기다려야 하며 그때 올바른 태그일 확률은 1/15임
      이는 hardened_malloc의 다른 보안 속성과 잘 결합됨
      slab 할당과 가상 메모리에 대해 FIFO/무작위 격리 구역을 두어 재사용을 더 지연시키고 결정적이지 않게 만듦
      128k를 넘기 전까지는 서로 다른 할당 크기 클래스 간 메모리 위치를 절대 재사용하지 않고, 각 클래스는 다른 영역에 있으며 메타데이터는 모두 또 다른 예약 영역에 있음
      일반적인 경우 MTE는 현재 4비트뿐이라 우회 확률이 약 1/15임
      8비트 사용 지원으로 쉽게 확장할 수 있고, PAC를 쓰지 않는다면 다른 여유 비트도 있음
      이론적으로 일반적인 39비트 주소 공간에서는 48비트 주소 공간 이상에 대해 최대 16비트 MTE도 지원할 수 있음
      현재 4비트로 고정돼 있는데, ECC 패리티 메모리에 추가 비트를 저장할 수 있게 하려고 8비트 대신 선택했다고 들었음
    • MTE는 오버헤드가 훨씬 낮고, 현재 실제 제품에 탑재돼 있으며, 일부 형태의 힙 손상을 감지할 수 있음
      하지만 CHERI만큼 신뢰성 있게 감지하지는 못함
      태그에 대한 보호가 없고 태그 공간도 작음(2^4)

  • 주류 하드웨어가 2015년 Solaris SPARC나 그 이전의 메모리 태그 아키텍처를 따라잡아서, 결국 메모리 손상 문제를 다스릴 날이 기다려짐
    물론 그 문제들은 실력 없는 개발자들만 만든다는 식으로 치부되곤 함

    • 이 말은 엄청 다운보트될 수 있겠지만, 그렇다면 그 사람들이 바로 버그를 쓰는 사람들임
      이건 “실력 없는 개발자” 문제가 아니라 모두의 문제임
      메모리 손상은 사실상 C/C++의 언어 기능에 가까움
      멍청한 사람들 때문이라는 믿음을 퍼뜨리지 않는 게 좋음
      스스로 멍청하다고 생각하는 사람은 거의 없고, 정말 뛰어난 코더들도 웃긴 메모리 버그를 만드는 걸 봤음
      그냥 그 언어들의 영역에 포함된 일이고, “만약”이 아니라 “언제”의 문제임

  • Android가 Bluetooth 코드 상당 부분을 Rust로 옮겼고, 나머지 코드도 Rust로 옮기는 데 더 많은 자원을 투입해야 하는 이유를 보여준다는 문장이 은근슬쩍 들어간 게 마음에 듦
    C와 C++를 여러 해 썼지만 Rust 경험은 없어서, C에서 Rust로 포팅할 때 리팩터링이 얼마나 필요한지 궁금함
    질문을 나누면, 1. C가 Rust로 얼마나 직접 번역되는가? Rust가 구조 재정리나 리팩터링을 요구하는가?
    2. Google은 이를 어떻게 접근하고 있는가? 최대한 가깝게 “번역”하려는지, 아니면 대규모 재작성·리팩터링 기회로 보는지 궁금함
    Android Bluetooth 스택이 언젠가 표준 Linux 배포판 데스크톱 시스템에서 사용할 수 있게 될지도 궁금함

    • 최근 미완성 실험으로 PIC 마이크로컨트롤러 시뮬레이터를 C++에서 Rust로 포팅해보려 했음
      순환 참조가 많아서, 모듈들이 콜백이 있는 “신호 버스”를 통해 서로 통신하는 구조였고 Rust가 도움이 되기보다 싸워야 하는 느낌이 컸음
      C++에서는 데이터를 인라인으로 저장할 수 있던 곳에도 heap 포인터인 Box가 많이 필요했음
      결론적으로 단순한 명령줄 도구나 요청-응답 구조라면 Rust 포팅이 아마 쉬움
      더 일반적으로 코드 구조가 아레나 할당과 잘 맞는다면 참조에 수명 태그를 붙이는 방식으로 옮기는 게 큰 문제가 아님
      하지만 C 프로그래머식으로 순환 참조가 있는, 인정하건대 못생긴 코드를 작성했다면 Rust는 오르막길처럼 느껴지고 거기서 시작할 만한 곳이 아님
      먼저 C++ 코드 구조를 바꿔 소유권을 공통 부모로 옮겨야 함
      그러면 나아질 것 같음
      Rust를 반복적으로 더 배우되, 코드가 Rust와 더 잘 대응될 때까지는 C++에서 계속 작업하려고 함
    • 1:1 포팅과는 꽤 거리가 멀 가능성이 큼
      작성 중인 것의 상당 부분을 다시 아키텍처화해야 할 것임
      Rust가 메모리 안전성을 보장하는 방식 때문에 피할 수 없음
답변달기