2025년 6월 30일 (월) 05:35에 Ahn9807님의 편집

2025-06-30T05:35:01Z

← 이전 판		2025년 6월 30일 (월) 05:35 판
18번째 줄:		18번째 줄:
	* Poisoning: 레드존(Redzone, 보호용 패딩 영역)에 대해 의도적으로 유효하지 않은 값(poison)을 채워 넣는 작업을 생략		* Poisoning: 레드존(Redzone, 보호용 패딩 영역)에 대해 의도적으로 유효하지 않은 값(poison)을 채워 넣는 작업을 생략
	* Logging: malloc, free 등의 시점에 생성되는 스택 트레이스 로그를 포함하여, 중간 로깅 작업을 제거		* Logging: malloc, free 등의 시점에 생성되는 스택 트레이스 로그를 포함하여, 중간 로깅 작업을 제거
	AddressSanitizer가 자체적으로 제공하는 힙 관리 기능을 비활성화하고, 표준 C 라이브러리의 기본 힙 할당/해제 ~~방식으로 복귀한다. 이는 호환성과 성능을 높이는 데 기여할 수 있다.~~		* Heap Management: AddressSanitizer가 자체적으로 제공하는 힙 관리 기능을 비활성화하고, 표준 C 라이브러리의 기본 힙 할당/해제 방식 사용
	* Redzone: 메모리 할당 주변에 삽입되는 레드존 영역과 관련된 모든 동작을 제거		* Redzone: 메모리 할당 주변에 삽입되는 레드존 영역과 관련된 모든 동작을 제거

			위의 표에서 볼수 있듯, SPEC CPU 2006을 돌리는데 걸리는 오버헤드는 대략 107.8%였다. 그중에서 메모리 접근시 수행되는 Check가 대략 오버헤드중에서 80.8%인 대부분을 차지하였다. 80.8%의 오버헤드중에서 Sequential code checking이 대략 절반정도(55%)를 차지하였다. Perlbench에서는 Heap management를 체크하는데 대략 39%정도의 오버헤드를 차지하였으며, Sanitizer check와 Heap management를 제외한 나머지는 평균 2%-3%정도로 미미한 수준을 기록하였다.

			추가적으로, ASan에서 사용하는 Shadow memory의 크기도 ASan의 성능에 영향을 주었다. Shadow memory크기가 작을 수록, Shadow page에 의해서 발생하는 Page fault수가 줄어들기 때문이다. Shadow memory의 크기를 Addr >> 3에서 Addr >> 36으로 줄였을떄, ASan성능은 대략 11.5%정도 향상되었다.

	== Design (Optimization) ==		== Design (Optimization) ==
	* Optimization 1: Static analysis를 통해서 확실하게 Bound check를 정적인 시간에 할 수 있는 경우, 해당 메모리 접근에 대한 Sanitizer검사를 제거		* Optimization 1: Static analysis를 통해서 확실하게 Bound check를 정적인 시간에 할 수 있는 경우, 해당 메모리 접근에 대한 Sanitizer검사를 제거
	* Optimiztaion 2: Sanitizer check중에서 다른 검사에 의해서 중복되는 검사를 제거		* Optimiztaion 2: Sanitizer check중에서 다른 검사에 의해서 중복되는 검사를 제거
	* Optimization 3: 물리적으로 인접한 메모리 접근을 식별해서, 해당 검사를 하나로 병합		* Optimization 3 <논문에서 처음 제시됨>: 물리적으로 인접한 메모리 접근을 식별해서, 해당 검사를 하나로 병합
	* Optimization 4: 불변 주소를 사용하는 메모리 접근을 찾아서, Sanitizer검사를 루프 밖으로 이동시켜, 루프내의 반복적인 검사를 하나로 통합하고, 증가하거나 감소하는 주소를 찾아 Iteration간의 검사를 하나로 통합		* Optimization 4 <논문에서 처음 제시됨>: 불변 주소를 사용하는 메모리 접근을 찾아서, Sanitizer검사를 루프 밖으로 이동시켜, 루프내의 반복적인 검사를 하나로 통합하고, 증가하거나 감소하는 주소를 찾아 Iteration간의 검사를 하나로 통합

			== Evaluation ==
			SPEC CPU 2006에서 94.86%의 성능 오버헤드가 발생한 ASan과 비교하여 대략 52.89%정도의 성능 오버헤드가 발생였다. 메모리 오버헤드는 리포트 되지 않았다.

			== [[Conclusion]] ==
			메모리 오버헤드에 대한 정량적 리포트가 포함되지 않은 점은 아쉬운 부분이다. 그러나 본 논문에서 제시한 정밀한 분석과 일련의 최적화 기법은 AddressSanitizer(ASan)의 메모리 오버헤드를 이해하고 평가하는 데 있어 유용한 출발점이 된다. 특히, 다양한 최적화 단계가 오버헤드 감소에 어떻게 기여하는지를 구조적으로 설명하고 있어, 후속 연구에 실질적인 참고 자료로 활용될 수 있다.

Ahn9807: 새 문서: 분류: USENIX Security Yuchen Zhang, Chengbin Pang, Georgios Portokalidis, Nijos Triandopoulos, Jun Xu USENIX Security 2022 == 개요 == AddressSanitizer의 성능 분석과, 그에 대한 여러가지의 Optimization technique를 제시한 논문이다. == Motivation & Importance == ASAN은 강력한 '''Capability''', '''Scalability''', '''Usability'''덕분에 많이 사용되는 Memory Santizier이다. 그러나 ASAN은 대략 1.5x-3.x의 메모리 오버헤드...

2025-06-30T05:01:01Z

새 문서: 분류: USENIX Security Yuchen Zhang, Chengbin Pang, Georgios Portokalidis, Nijos Triandopoulos, Jun Xu USENIX Security 2022 == 개요 == AddressSanitizer의 성능 분석과, 그에 대한 여러가지의 Optimization technique를 제시한 논문이다. == Motivation & Importance == ASAN은 강력한 '''Capability''', '''Scalability''', '''Usability'''덕분에 많이 사용되는 Memory Santizier이다. 그러나 ASAN은 대략 1.5x-3.x의 메모리 오버헤드...

새 문서

[[분류: USENIX Security]]

Yuchen Zhang, Chengbin Pang, Georgios Portokalidis, Nijos Triandopoulos, Jun Xu
USENIX Security 2022

== 개요 ==
[[AddressSanitizer]]의 성능 분석과, 그에 대한 여러가지의 Optimization technique를 제시한 논문이다.

== Motivation & Importance ==
ASAN은 강력한 '''Capability''', '''Scalability''', '''Usability'''덕분에 많이 사용되는 Memory Santizier이다. 그러나 ASAN은 대략 1.5x-3.x의 메모리 오버헤드가 대략 200%가 넘는 Performance overhead가 발생한다는 성능상의 단점이 있다.

따라서, 위의 언급한 3개의 장점을 해치지 않으면서, 최대한 성능을 최적화 하기 위한 기법을 개발하는 것이 중요하다.

== Asan 성능 분석 ==
[[파일:USENIX Security 2022 ASan-- Figure 3.png|섬네일|가운데|800픽셀]]
* Sanitizer Checks: 메모리 접근(읽기 및 쓰기)에 대해 삽입된 Sanitizer 검사를 비활성화
* Interceptor: memcpy, memset, memmove 등 표준 C 라이브러리 함수 호출을 감시하거나 가로채는 인터셉터 기능을 제거
* Poisoning: 레드존(Redzone, 보호용 패딩 영역)에 대해 의도적으로 유효하지 않은 값(poison)을 채워 넣는 작업을 생략
* Logging: malloc, free 등의 시점에 생성되는 스택 트레이스 로그를 포함하여, 중간 로깅 작업을 제거
AddressSanitizer가 자체적으로 제공하는 힙 관리 기능을 비활성화하고, 표준 C 라이브러리의 기본 힙 할당/해제 방식으로 복귀한다. 이는 호환성과 성능을 높이는 데 기여할 수 있다.
* Redzone: 메모리 할당 주변에 삽입되는 레드존 영역과 관련된 모든 동작을 제거

== Design (Optimization) ==
* Optimization 1: Static analysis를 통해서 확실하게 Bound check를 정적인 시간에 할 수 있는 경우, 해당 메모리 접근에 대한 Sanitizer검사를 제거
* Optimiztaion 2: Sanitizer check중에서 다른 검사에 의해서 중복되는 검사를 제거
* Optimization 3: 물리적으로 인접한 메모리 접근을 식별해서, 해당 검사를 하나로 병합
* Optimization 4: 불변 주소를 사용하는 메모리 접근을 찾아서, Sanitizer검사를 루프 밖으로 이동시켜, 루프내의 반복적인 검사를 하나로 통합하고, 증가하거나 감소하는 주소를 찾아 Iteration간의 검사를 하나로 통합

Debloating Address Sanitizer - 편집 역사

2025년 6월 30일 (월) 05:35에 Ahn9807님의 편집