메뉴 여닫기
환경 설정 메뉴 여닫기
개인 메뉴 여닫기
로그인하지 않음
지금 편집한다면 당신의 IP 주소가 공개될 수 있습니다.

Sticky Tags: Efficient and Deterministic Spatial Memory Error Mitigation using Persistent Memory Tags

noriwiki
Ahn9807 (토론 | 기여)님의 2025년 5월 27일 (화) 03:50 판
(차이) ← 이전 판 | 최신판 (차이) | 다음 판 → (차이)


Floris Gorter, Taddeus Kroes, Herbert Bos and Cristiano Giuffrida
IEEE S&P 2024

개요

ARM MTE는 강력한 Lock-key매커니즘을 제공하지만 Random한 검출 방식이라는 문제가 있다. StickyTag는 이 문제를 stack 그리고 heap layout을 per-size-class region으로 구성하여서, Persistent memory tag를 각 Region에 부여하는 방식으로 Determinstic한 spatial bug검출 방식을 제시하였다.

Motivation & Importance

Spatial버그는 중요한 버그이다. 기존 MTE를 활용한 방식들은 Random tag를 Frequent하게 바꾼다거나, 아니면 Probablistic한 모델에 의존한다는 단점이 있었다. 특히 Probablistic한 모델은 Brute-forcing이나 Speculative attack에 취약하다는 점으로 인해서 사용하기 어렵다고 주장한다.

MTE는 공격자에게 태그 불일치 여부를 판별할 수 있는 Side channel을 노출한다. 공격자는 추측 실행 경로(speculative path) 상에서 대상 소프트웨어 취약점을 유발하고, 추측 실행 창 내의 메모리 연산으로부터의 신호를 관찰하여 공격한다. 이는 특히 무차별 대입이 불가능한 상황에서도 마찬가지이다. 따라서, StickTag는 구글이 최근 디바이스에서는 사이드 채널이 존재하지 않는다는 주장이 틀렸다고 주장한다.

따라서 MTE를 활용해서 안전한 Spatial버그를 막는 기술을 고도화할 필요가 있다.

Design

MTE Retagging overhead를 줄이기 위해서, 각 StackHeap영역을 Size class로 묶고, 각 side class마다 Round robin방식으로 서로 다른 MTE Tag를 할당하여서, Spatical Error을 방지할 수 있도록 하였다. Spatial Tag는 Deterministic하게 배정되기 때문에, 기존처럼 Frequent하게 MTE Tag를 배정함으로서 발생하는 Performance 문제를 예방할 수 있다.

Persistent Memory Tag Initialization
StickTag는 Page를 Allocating할때마다 MTE로 Memory를 Tagging해야 한다.
  • Memory에 접근할때마다, Metadata를 확인해서 Tagging되었나 체크하기: Fast-path에서의 Metadata를 살피는 비용이 큼
  • Memroy Chunk를 할당할때 미리 Tagging하기: Performance + Memory overhead가 커짐

이 문제를 하결하기 위해서, Memory가 접근될경우 Userfaultfd를 이용해서 Page fault handler를 User-level에서 처리하여 동적으로 Memory를 Tagging하였다.

Huge objects
262KB이상의 큰 오브젝트와 같은 경우에는 Guard page를 이용하여서 Spatial bug를 예방하였다.
X86에의 적용
X86과 같은 경우에는 MTE가 없기 때문에, Compiler와 Guard page로만 구현해야 한다. AddressSanitizer과 같은 경우에는 Shadow Memory를 사용해서, 특정 메모리 영역이 Valid한지를 저장하였다. 이 방식과는 다르게 StickTag-x86에서는 RedZone이라는 구역을 정해진 위치에 할당하였다. 이를 통해서 RedZone이 어딘지 확인하는 Shadow memory checking cost를 줄일 수 있었다. 매 Read/Write시에 현재 접근이 RedZone인지 아닌지를 확인하는 Instruction을 Static Compiler를 통해서 삽입하였다. 이를 효과적으로 하기 위해서는, RedZone에 Guard value를 넣고, 이 값인지 아닌지 체크하는 Fast-path를 넣었다. 이 Guard page checking을 위해서는 RedZone에 해당하는 영역을 초기화 시켜주어야 하는데, 이는 Page fault시에 on-demand로 Initialize하였다.

Evaluation

Performance는 대략4%정도의 휼용한 결과를 얻었지만, Memory overhead가 거의 없는 MemTagSanitizer와 비교하여서 15.7%의 다소큰 메모리 오버헤드가 발생하였다. 이 메모리 오버헤드는 16바이트라는 MTE의 Boundary에 맞추기 위하여 더한 Padding에서 발생하였다.

Conclusion

본 논문의 주된 Spatial memory bug를 막는 아이디어는 간단한 아이디어지만, Motivation으로든 MTE의 Vulneability와 매우 빠른 Evaluation성능이 주목할 만 하다. 또한 Userfaultfd를 사용해서 On-demandly하게 Initializing하고 있는 흥미로운 Userfaultfd의 활용예를 보여준다.