Floris Gorter, Cristiano Giuffrida USENIX Security 2025
개요
기존의 RedZone을 이용한 Code sanitizer들은 매 오브젝트마다 Metadata를 할당해야 해서, 큰 메모리 오버헤드가 발생하였다. RSan은 Range check을 통해서 Metadata memory overhead를 줄였고, 추가적으로 Metadata searching cost도 줄였다.
Motivation & Importance
AddressSanitizer는 RedZone기반의 방식을 사용한다. 그러나 ASan은 RedZone으로 인해서 포인터가 Valid한지 체크하는 과정에 성능 저하가 발생한다. ASan은 포인터가 Valid한지 체크하기 위해서, 모든 Buf부터 Lenght에 해당하는 모든 Shadow memory를 8byte씩 Scanning해야 하기 때문이다 (즉 오버헤드는 O(N)이다). 따라서 이 오버헤드를 극복할 수 있도록 Metadata를 효율적으로 만드는 법은 없을지에 대한 탐구가 필요하다.
Main Idea
- 우선 RedZone을 넣는다.
- Size + RedZone + Pad값을 더한 결과가 2의 N승이 될수 있도록 Pad크기 만큼 RedZone크기를 늘린다.
- 앞의 8바이트에 (즉 전 Allocation의 RedZone + Pad)에 Base Address를 저장한다.
- ARM Top Byte Ignore나 Intel Linewar Address Masking을 사용하여서 전체 크기가 몇 승인지 (N)인지 태그한다.
- <Pointer Checking> Tag를 통해서 오브젝트의 크기를 얻는다.
- <Pointer Checking> 오브젝트의 크기를 통해서 Base offset을 구하여, Base address를 구한다.
- <Pointer Checking> 최종적으로 O(1)으로 현재 접근하는 오브젝트가 Valid한지를 체크할 수 있다.
이를 통하여, Shadow Memory를 없앨 수 있고, O(1)시간에 Pointer가 Valid한지를 체크할 수 있다.
Design
이외에도 논문에는 각 Step들의 자세한 Design choice와 구현, 그리고 추가적인 Compiler Optimization까지 어떻게 수행하였는지 상세히 서술 되어 있다.
Evaluation
SPEC CPU 2006에서 대략 51%의 Performance overhead가 발생하였으며, 228%정도의 메모리 오버헤드가 발생하였다. 기존의 ASan은 대략 86.7%의 Performance overhead와 187%의 메모리 오버헤드가 발생하였다는 점에서 Performance 성능은 올라갔지만 메모리 오버헤드는 다소 증가한 Evaluation결과를 얻을 수 있었다.