noriwiki - 최근 바뀜 [ko]

소목 정석 1

Ahn9807 — Sat, 31 Oct 2026 17:10:43 GMT

새 문서: 분류:소목 정석 == 마늘모 굳힘 == <goban mode="player" view="H14:T19" move="4" from="0" to="4" autoplay="1000" loop="false" showControls="false" showMoveNumber="true" align="center" width="0"> (;GM[1]FF[4]CA[UTF-8]SZ[19] ;B[qd] (;W[oc] ;B[pe] ;W[lc] )(;W[od] )) </goban> 마늘모 굳힘은 소목에 날일자 걸침이 왔을 때 가장 간명하게 대응할 수 있는 방법 중 하나이다. 백 2로 걸쳐 오면 흑은 3으로 마늘모 응수를 하여...

새 문서

[[:분류:소목 정석]]

== 마늘모 굳힘 ==
<goban mode="player" view="H14:T19" move="4" from="0" to="4" autoplay="1000" loop="false" showControls="false" showMoveNumber="true" align="center" width="0">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[qd]
(;W[oc]
;B[pe]
;W[lc]
)(;W[od]
))
</goban>

마늘모 굳힘은 소목에 날일자 걸침이 왔을 때 가장 간명하게 대응할 수 있는 방법 중 하나이다.

백 2로 걸쳐 오면 흑은 3으로 마늘모 응수를 하여 귀를 안정시킨다. 이후 백이 4로 윗변에 벌리면 흑은 다른 큰 자리로 손을 뺄 수 있다.

이 정석은 복잡한 전투를 피하면서 자신의 돌을 안정시키고, 다른 큰 자리를 차지할 수 있다는 장점이 있다.

== 한 칸 뛰기 ==
<goban mode="player" view="A1:M7" move="8" from="0" to="8" autoplay="1000" loop="false" showControls="false" showMoveNumber="true" align="center" width="0">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
(;B[cp]
;W[ep]
;B[eq]
;W[fq]
;B[dq]
;W[fp]
;B[cn]
;W[jp]
)(;B[]
;W[cp]
))
</goban>

흑은 귀의 실리를 확보하고, 백은 바깥으로 세력을 형성하면서 하변으로 발전할 수 있는 공간을 얻는다.

흑 7로 좌변의 근거를 마련하면 백은 8로 하변에 넓게 벌린다. 흑은 귀와 좌변에서 안정적인 집을 확보하고, 백은 하변의 발전 가능성을 얻으므로 양쪽 모두 만족할 만한 진행이다.

== 흑의 한 칸 협공 ==
<goban mode="player" view="A1:T7" move="7" from="0" to="7" autoplay="1000" loop="false" showControls="false" showMoveNumber="true" align="center" width="0">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[jp]
;W[dp]
;B[qp]
;W[op]
;B[mp]
;W[on]
;B[qn]
)
</goban>

흑은 이미 하변에 자신의 돌이 있으므로 백 4의 걸침에 5로 한 칸 협공을 선택하였다.

백은 6으로 뛰어 중앙으로 진출하지만, 흑 7까지 진행되면 양쪽의 흑돌에 압박받아 근거가 부족한 미생마가 되기 쉽다. 반면 흑은 기존의 하변 배석을 활용하여 백을 공격하면서 자신의 세력을 강화할 수 있다.

이러한 진행에서 백이 불만인 이유는 처음부터 흑의 세력이 강한 방향으로 걸쳐 들어갔기 때문이다. 따라서 상대의 강한 돌이 있는 방향으로 무리하게 접근하지 않는 것이 중요하다.

<goban mode="player" view="A12:M19" move="14" from="0" to="14" autoplay="1000" loop="false" showControls="false" showMoveNumber="true" align="center" width="0">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[cd]
;W[ec]
;B[gd]
;W[ee]
;B[df]
;W[id]
;B[gf]
;W[gc]
;B[fd]
;W[fc]
;B[ed]
;W[dc]
;B[dd]
;W[cc]
)
</goban>

위의 그림은 협공을 당했을 때의 또 다른 대응 방법이다. 백은 4의 돌을 반드시 살리려고 하지 않고, 필요하다면 버리는 것을 감수하면서 바깥의 흑돌을 견제한다. 그 결과 백은 윗변의 실리를 확보하고, 흑은 바깥의 두터움과 세력을 얻게 된다.

여기서 핵심은 '''백 6으로 되협공하는 수'''이다.

흑 3으로 협공을 당했을 때 백이 곧바로 귀로 들어가 삶을 도모하면, 흑은 양쪽 변으로 세력을 넓히면서 큰 진형을 형성할 수 있다. 반면 백은 귀에서 살아도 바깥으로 발전하기 어려워질 수 있다.

따라서 백은 6으로 흑의 협공에 맞서면서 바깥의 흑 세력을 견제한다. 이후의 진행에서는 백이 윗변의 실리를 얻고, 흑은 바깥으로 두터운 모양을 만드는 방향으로 정리된다.

'''협공을 선택할 때 중요한 것은 주변의 배석이다.''' 흑은 바깥에 자신의 돌이 있어 협공의 효과를 높일 수 있을 때 이러한 정석을 선택하는 것이 좋다. 주변의 지원 없이 무리하게 협공하면 오히려 자신의 돌이 약해질 수 있다.

대문

Ahn9807 — Sat, 31 Oct 2026 14:21:48 GMT

← 이전 판		2026년 10월 31일 (토) 14:21 판
61번째 줄:		61번째 줄:
	<categorytree mode="pages" namespaces="Main Category">바둑</categorytree>		<categorytree mode="pages" namespaces="Main Category">바둑</categorytree>
	</div>		</div>
	</div>		<div style="clear:both"></div>
	\|-\|Liberal Arts=		\|-\|Liberal Arts=
	<div class="home-card">		<div class="home-card">

분류:소목 정석

Ahn9807 — Sat, 31 Oct 2026 14:20:32 GMT

새 문서: 분류: 정석

새 문서

[[분류: 정석]]

분류:포석

Ahn9807 — Sat, 31 Oct 2026 14:19:26 GMT

새 문서: 분류: 바둑

새 문서

[[분류: 바둑]]

소목 포석

Ahn9807 — Sat, 31 Oct 2026 14:19:17 GMT

새 문서: 분류: 포석 분류:소목 정석 == 개요 == '''소목(小目)'''은 귀의 실리를 중시하면서 변으로 발전할 수 있는 착점이다. 화점과 달리 비대칭적인 위치에 있으므로, 돌을 놓는 방향에 따라 이후의 발전 방향이 달라진다. 또한 귀를 적절히 굳히면 상대의 삼삼 침입에 대응하기 쉽다. 소목을 활용한 포석에서는 귀를 굳히는 대신 변으로 넓게 벌려 상대의 발전...

새 문서

[[분류: 포석]]
[[분류:소목 정석]]

== 개요 ==
'''소목(小目)'''은 귀의 실리를 중시하면서 변으로 발전할 수 있는 착점이다. [[화점]]과 달리 비대칭적인 위치에 있으므로, 돌을 놓는 방향에 따라 이후의 발전 방향이 달라진다. 또한 귀를 적절히 굳히면 상대의 삼삼 침입에 대응하기 쉽다.

소목을 활용한 [[포석]]에서는 귀를 굳히는 대신 변으로 넓게 벌려 상대의 발전 공간을 제한하는 전략을 사용할 수 있다. 대표적인 형태로 '''중국식, 일본식, 한국식'''이 있으며, 벌림의 위치와 방향에 따라 구분한다.

이러한 포석의 공통된 목적은 상대가 걸쳐 왔을 때 벌리거나 근거를 마련하려는 자리를 미리 차지하여, 상대의 활동을 제한하면서 자신의 진형을 유리하게 만드는 것이다.

== 중국식 ==
<goban mode="player" move="9" from="0" to="9" autoplay="1000" loop="false" showControls="false" showMoveNumber="true" align="none" width="0">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[dp]
;W[pd]
;B[pq]
;W[dd]
;B[pk]
;W[qo]
;B[qp]
;W[oo]
;B[mp]
)
</goban>

'''중국식'''은 소목에서 귀를 굳히지 않고 변의 4선으로 넓게 벌리는 포석이다.

위 그림에서 흑 5는 우변의 큰 자리를 미리 차지하는 수이다. 이후 백이 6으로 걸쳐 오더라도 흑은 이미 우변에 포진해 있으므로, 백이 자유롭게 벌리거나 근거를 마련하기 어렵게 만든다.
즉, 중국식은 상대가 벌리고 싶은 자리를 선점하여 활동 공간을 제한하면서 자신의 세력을 넓히는 포석이다.

== 일본식 ==
<goban mode="player" view="A1:T8" move="5" from="0" to="5" autoplay="1000" loop="false" showControls="false" showMoveNumber="true" align="none" width="0">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[pq]
;W[cp]
;B[jp]
;W[po]
;B[pm]
)
</goban>

'''일본식'''은 소목에서 하변의 4선으로 넓게 벌리는 포석이다.

위 그림에서 흑 3은 하변의 큰 자리를 차지하여 자신의 진형을 넓히는 수이다. 이후 백이 4로 걸쳐 오면 흑은 5로 우변을 벌려 자신의 발전 공간을 확보한다.
이처럼 일본식은 변의 큰 자리를 미리 차지하여 상대의 활동을 견제하고, 넓은 진형을 구축하는 데 목적이 있다.

== 한국식 ==
<goban mode="player" view="A1:T5" move="3" from="0" to="3" autoplay="1000" loop="false" showControls="false" showMoveNumber="true" align="none" width="0">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[qp]
;W[dp]
;B[kq]
)
</goban>

'''한국식'''은 소목에서 상대의 돌이 있는 방향으로 3선에 넓게 벌리는 포석이다.

위 그림에서 흑 3은 백 2가 있는 하변 쪽으로 미리 포진하는 수이다. 상대가 하변에서 벌리거나 발전하고 싶은 자리를 흑이 선점함으로써, 백의 활동 공간을 제한하는 효과가 있다.
특히 4선 벌림이 세력과 발전 가능성을 중시한다면, 3선 벌림은 변의 실리와 안정적인 근거를 상대적으로 중시한다.

== 벌림의 기본 원리 ==
중국식, 일본식, 한국식은 벌림의 위치와 방향에 차이가 있지만, 공통적으로 '''상대가 벌리고 싶은 자리를 미리 차지한다'''는 원리를 활용한다. 상대가 걸쳐 왔을 때 자유롭게 세 칸 정도 벌릴 수 있는 공간을 미리 제한하면, 상대는 근거를 마련하기 어려워지고 자신의 돌은 유리한 방향으로 발전할 수 있다.

다만 벌림의 방향은 주변의 배석에 따라 결정해야 한다. 상대의 발전을 제한하는 것뿐 아니라 자신의 돌이 효율적으로 연결되고 발전할 수 있는지도 함께 고려하는 것이 중요하다.

대문

Ahn9807 — Sat, 31 Oct 2026 14:00:56 GMT

← 이전 판		2026년 10월 31일 (토) 14:00 판
55번째 줄:		55번째 줄:
	\|-\|Hobby=		\|-\|Hobby=
	<div class="home-card">		<div class="home-card">
			<div class="main-top-left" style="float:left">
	<categorytree mode="pages" namespaces="Main Category">필름 카메라</categorytree>		<categorytree mode="pages" namespaces="Main Category">필름 카메라</categorytree>
			</div>
			<div class="main-top-left" style="float:left">
			<categorytree mode="pages" namespaces="Main Category">바둑</categorytree>
			</div>
	</div>		</div>
	\|-\|Liberal Arts=		\|-\|Liberal Arts=

화점 정석 2

Ahn9807 — Sat, 31 Oct 2026 13:56:35 GMT

새 문서: 분류:화점 정석 == 개요 == '''화점 정석 2'''는 굳힘이 아니라 '''협공'''을 선택한 경우이다. 협공은 걸쳐 온 상대 돌을 바로 굳혀 주지 않고 압박하면서, 바깥 세력과 주도권을 얻기 위해 선택하는 수법이다. 보통 협공하는 쪽의 바깥에 이미 아군의 배석이 있을 때 효과가 크며, 이런 경우 협공을 통해 판을 넓게 운영할 수 있다. 협공은 즉시 집을 많이 얻는 진행...

새 문서

[[:분류:화점 정석]]

== 개요 ==
'''화점 정석 2'''는 굳힘이 아니라 '''협공'''을 선택한 경우이다. 협공은 걸쳐 온 상대 돌을 바로 굳혀 주지 않고 압박하면서, 바깥 세력과 주도권을 얻기 위해 선택하는 수법이다. 보통 협공하는 쪽의 바깥에 이미 아군의 배석이 있을 때 효과가 크며, 이런 경우 협공을 통해 판을 넓게 운영할 수 있다.

협공은 즉시 집을 많이 얻는 진행이라기보다는, 상대에게 귀의 실리를 주는 대신 자신은 바깥의 두터움과 큰 세력을 얻는 진행이라고 할 수 있다.

<goban mode="player" from="0" autoplay="1000" loop="false" showControls="false" showMoveNumber="true" move="13" to="13" view="A1:T7">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[dp]
;W[fq]
;B[hq]
;W[cq]
;B[dq]
;W[cp]
;B[do]
;W[dr]
;B[er]
;W[cr]
;B[eq]
;W[cn]
;B[pp]TR[pp]
)
</goban>

협공을 선택하면 바깥 모양과 세력을 만들기 위한 방향으로 진행되는 경우가 많다. 위의 진행에서는 세모(△) 위치에 흑의 배석이 있으므로 협공을 선택하였다. 백은 삼삼 침입을 통해 귀의 실리를 얻었고, 흑은 즉시 확보한 집은 상대적으로 적지만 좌변과 좌하귀 방면에 큰 세력을 얻게 되었다. 이런 결과는 실리와 세력을 나누어 갖는 대표적인 협공형 정석이다.

<goban mode="player" view="A1:T6" move="11" from="0" to="11" autoplay="1000" loop="false" showMoveNumber="true" showControls="false">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[dp]
;W[fq]
;B[hq]
;W[fo]MA[fo]
;B[pp]
;W[nq]
;B[lq]
;W[qq]
;B[pq]
;W[]
;B[qp]CR[pq]MA[qp]
)
</goban>

백의 입장에서 협공을 당했을 때 반사적으로 위로 뛰는 수는 좋은 대응이 아니다. 위 그림의 백 4처럼 뛰게 되면, 흑은 귀와 변에서 집을 확보하면서도 계속해서 백을 압박할 수 있다. 반면 백은 근거가 불충분한 미생마가 되어 쫓겨다니기 쉬워진다.

또한 백이 삼삼에 들어왔을 때 흑이 막는 기본 원칙은, 상대 돌이 바깥과 쉽게 연결되지 못하도록 '''연결을 끊는 방향'''으로 막는 것이다. 즉, 단순히 귀를 지키는 것에 그치지 않고 바깥 세력까지 의식하여 응수해야 한다.

<goban mode="player" view="A1:T11" move="11" from="0" to="11" autoplay="1000" loop="false" showMoveNumber="true" showControls="false">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[dp]
;W[]
;B[dj]
;W[fq]
;B[hq]
;W[cq]
;B[cp]
;W[dq]
;B[ep]
;W[fr]
;B[go]
)
</goban>

위의 수순도 하나의 정석으로 볼 수 있다. 다만 백의 입장에서는 흑에게 바깥의 큰 세력을 허용하게 되므로 다소 불만인 진행이다. 프로 수준에서는 이후 침입과 삭감의 여지가 충분하므로 큰 문제가 아닐 수 있지만, 아마추어에게는 저러한 큰 세력을 상대하는 일이 쉽지 않다. 따라서 실전에서는 백이 더 부담을 느끼기 쉬운 변화라고 할 수 있다.

이럴 경우에는 다음과 같은 진행이 백에게 더 만족스럽다.

<goban mode="player" view="A9:T19" move="12" from="0" to="12" autoplay="1000" loop="false" showMoveNumber="true" showControls="false">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[dd]
;W[]
;B[dj]
;W[fc]
;B[hc]
;W[df]
;B[fd]
;W[gd]
;B[gc]
;W[cd]
;B[ec]
;W[cc]
)
</goban>

위와 같이 백이 6부터 이어지는 수순을 두면, 흑의 진형을 견제하면서 동시에 실리도 확보할 수 있다. 즉, 흑의 바깥 세력을 그대로 키워 주지 않으면서 백도 집을 얻을 수 있으므로, 백에게는 보다 만족스러운 진행이다.

결국 협공 정석에서는 '''귀의 실리와 바깥 세력 중 무엇을 선택할 것인가'''가 핵심이 된다. 흑은 협공을 통해 외세와 주도권을 얻고, 백은 그 세력을 지나치게 키워 주지 않으면서 실리를 확보하는 방향으로 대응하는 것이 중요하다.

정석

Ahn9807 — Sat, 31 Oct 2026 13:41:46 GMT

← 이전 판		2026년 10월 31일 (토) 13:41 판
1번째 줄:		1번째 줄:

	[[분류:바둑]]		[[분류:정석]]

	== 개요 ==		== 개요 ==

분류:정석

Ahn9807 — Sat, 31 Oct 2026 13:41:26 GMT

새 문서: 분류: 바둑

새 문서

[[분류: 바둑]]

화점 정석

Ahn9807 — Sat, 31 Oct 2026 13:41:20 GMT

← 이전 판		2026년 10월 31일 (토) 13:41 판
1번째 줄:		1번째 줄:
	[[:분류:바둑]]		[[:분류:정석]]

분류:화점 정석

Ahn9807 — Sat, 31 Oct 2026 13:40:27 GMT

새 문서: 분류: 정석

새 문서

[[분류: 정석]]

화점 정석 1

Ahn9807 — Sat, 31 Oct 2026 13:39:46 GMT

← 이전 판		2026년 10월 31일 (토) 13:39 판
1번째 줄:		1번째 줄:
			[[분류: 화점 정석]]

	== 개요 ==		== 개요 ==
	'''화점 정석 1'''은 화점에 날일자 걸침이 왔을 때, 날일자 굳힘으로 응하는 정석 계열이다. 날일자 굳힘은 귀를 안정시키고 바깥 모양을 정돈한 뒤, 선수로 손을 빼어 판을 넓게 쓰기 위해 주로 사용된다.		'''화점 정석 1'''은 화점에 날일자 걸침이 왔을 때, 날일자 굳힘으로 응하는 정석 계열이다. 날일자 굳힘은 귀를 안정시키고 바깥 모양을 정돈한 뒤, 선수로 손을 빼어 판을 넓게 쓰기 위해 주로 사용된다.

화점 정석 1

Ahn9807 — Sat, 31 Oct 2026 13:39:22 GMT

새 문서: == 개요 == '''화점 정석 1'''은 화점에 날일자 걸침이 왔을 때, 날일자 굳힘으로 응하는 정석 계열이다. 날일자 굳힘은 귀를 안정시키고 바깥 모양을 정돈한 뒤, 선수로 손을 빼어 판을 넓게 쓰기 위해 주로 사용된다. <goban mode="player" from="0" autoplay="1000" loop="false" showMoveNumber="true" showControls="false" view="A10:T19" move="16" to="16"> (;GM[1]FF[4]CA[UTF-8]SZ[19] ;B[pd] ;W[qf] ;B[nc] ;W[pi] ;B[dd] ;...

새 문서

== 개요 ==
'''화점 정석 1'''은 화점에 날일자 걸침이 왔을 때, 날일자 굳힘으로 응하는 정석 계열이다. 날일자 굳힘은 귀를 안정시키고 바깥 모양을 정돈한 뒤, 선수로 손을 빼어 판을 넓게 쓰기 위해 주로 사용된다.

<goban mode="player" from="0" autoplay="1000" loop="false" showMoveNumber="true" showControls="false" view="A10:T19" move="16" to="16">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[pd]
;W[qf]
;B[nc]
;W[pi]
;B[dd]
;W[cf]
;B[fc]
;W[cd]
;B[cc]
;W[bc]
;B[ce]
;W[bd]
;B[de]
;W[be]
;B[df]
;W[cg]
)
</goban>

* 우상귀의 1~4는 비교적 간단한 진행으로, 흑은 귀를 안정시키고 백은 바깥쪽 발전의 여지를 얻는다.
* 좌상귀의 5~16은 최근 AI 이후 자주 등장하는 변화로, 전통적인 귀 침입보다 한 칸 높게 진입하는 것이 특징이다. 이 진행에서도 흑과 백은 각각 실리와 세력, 안정과 발전 가능성을 나누어 가지므로 서로 둘 만한 결과가 된다.

이후에는 국지전이 일단락되므로, 흑백 모두 다른 큰 자리로 손을 빼는 경우가 많다.

* 날일자 굳힘은 바깥 모양을 만들기 좋다. 그래서 굳힘은 보통 우리 돌이 있는 쪽, 즉 이후 판 전체의 흐름과 잘 어울리는 방향으로 두게 된다.
* 또한 날일자 굳힘은 국지적으로 안정된 형태를 갖추기 쉬워, 선수로 마무리하고 다른 큰 자리를 차지하는 데 유리하다.

예를 들어 굳힘 이후에는 다음과 같이 손을 뺄 수 있다.

<goban mode="player" view="A10:T19" move="9" from="0" to="9" autoplay="1000" loop="false" showMoveNumber="true" showControls="false">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[dd]
;W[cf]
;B[pd]
;W[nc]
;B[qf]
;W[pg]
;B[qg]
;W[pi]
;B[fc]
)
</goban>

흑이 5로 날일자 굳힘을 두면, 백은 6으로 압박하고 흑은 7로 받아 형태를 정비한다. 이어서 백이 8로 뛰면 우상귀의 국지전은 일단락된다. 이때 흑은 3~7의 형태가 단단하므로, 9와 같이 다른 큰 자리로 손을 뺄 수 있다. 즉, 굳힘은 내 세력을 강하게 하고 돌을 안정시켜, 선수로 국지전을 마무리할 수 있게 해 준다.

특히 다음과 같이 중복된 모양을 만드는 수순은 좋지 않다.

<goban mode="player" move="9" from="0" to="9" autoplay="1000" loop="false" showMoveNumber="true" view="A1:L11" showControls="false">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[dp]
;W[cn]
;B[fq]
;W[dk]
;B[bp]
;W[]
;B[iq]MA[bp][iq]
;W[]
;B[fo]MA[fo][bp][iq]
)
</goban>

위 수순에서 X로 표시된 자리들은 모두 흑 3 이후에 곧바로 두기에는 과밀한 자리들이다. 이미 흑 3으로 굳힘을 해 두었는데, 그 근처에 다시 덧붙여 두면 돌이 지나치게 붙어서 효율이 떨어진다. 즉, 흑 3의 굳힘은 선수를 얻어 큰 자리로 나가기 위한 수인데, 그 뒤에 중복된 모양을 만드는 수를 이어 두어서는 안 된다.

정석

Ahn9807 — Fri, 30 Oct 2026 14:52:34 GMT

← 이전 판		2026년 10월 30일 (금) 14:52 판
1번째 줄:		1번째 줄:

	[[~~index.php?title=~~분류:바둑]]		[[분류:바둑]]

	== 개요 ==		== 개요 ==

정석

Ahn9807 — Fri, 30 Oct 2026 14:52:26 GMT

새 문서: index.php?title=분류:바둑 == 개요 == '''정석(定石)'''은 바둑의 초반에 주로 귀에서 벌어지는 접전에서 흑과 백이 서로 합리적인 수를 교환하여 만들어지는 대표적인 진행을 말한다. 바둑의 초반은 포석과 정석이 서로 밀접하게 연결되어 있다. 포석이 바둑판 전체의 돌 배치와 방향을 결정한다면, 정석은 주로 귀를 중심으로 벌어지는 국지적인 접전의 진행을 다...

새 문서

[[index.php?title=분류:바둑]]

== 개요 ==
'''정석(定石)'''은 바둑의 초반에 주로 귀에서 벌어지는 접전에서 흑과 백이 서로 합리적인 수를 교환하여 만들어지는 대표적인 진행을 말한다.

바둑의 초반은 [[포석]]과 정석이 서로 밀접하게 연결되어 있다. 포석이 바둑판 전체의 돌 배치와 방향을 결정한다면, 정석은 주로 귀를 중심으로 벌어지는 국지적인 접전의 진행을 다룬다. 따라서 초반을 정확하게 운영하려면 정석의 수순뿐 아니라 포석의 방향과 [[행마]]의 원리를 함께 이해해야 한다.

정석의 변화는 매우 다양하며, 모든 정석을 외우는 것은 현실적으로 어렵다. 그러나 아마추어 수준에서는 대표적인 기본 정석을 익히고, 각 수의 목적과 원리를 이해하는 것만으로도 충분히 바둑을 즐길 수 있다.

== 정석의 원리 ==
정석은 대체로 귀의 접전에서 시작하여 변으로 근거를 넓히거나 중앙으로 진출하는 방향으로 전개된다. 특히 초보자와 아마추어는 귀의 작은 집을 지키는 데 지나치게 많은 수를 투자하는 경우가 있는데, 이러한 습관에 주의해야 한다.

초반에는 귀의 실리를 확보하는 것도 중요하지만, 변의 큰 자리를 차지하고 중앙으로 발전할 가능성을 남기는 것 역시 중요하다. 이미 안정된 귀에서 작은 집을 늘리기보다는 다른 큰 자리로 향하는 편이 효율적인 경우가 많다. 다만 귀에서 반드시 변을 거쳐 중앙으로 나가야 한다는 정해진 순서가 있는 것은 아니다. 주변의 배석과 돌의 안정 여부에 따라 귀를 지키거나, 변으로 벌리거나, 중앙으로 진출하는 수의 가치가 달라진다.

정석을 선택할 때는 다음의 세 가지 요소를 고려해야 한다.

# '''실리''': 귀와 변에서 확보할 수 있는 집의 가치
# '''세력''': 중앙이나 주변으로 발전할 수 있는 가능성
# '''안정과 효율''': 자신의 돌이 안전한지, 적은 수로 효율적인 모양을 만들었는지

또한 상대가 귀에 걸쳐 왔을 때는 크게 다음과 같은 대응을 생각할 수 있다.

# '''굳힘''': 귀를 보강하여 실리와 안정성을 확보한다.
# '''협공''': 걸쳐 온 상대의 돌을 공격하며 자신의 세력이나 발전 방향을 확보한다.
# '''손빼기''': 상대의 걸침에 즉시 대응하지 않고 다른 큰 자리를 차지한다.

이러한 선택은 주변의 포석과 상대 돌의 배치에 따라 달라진다.

== 정석의 조건 ==
정석은 흑과 백이 국지적인 접전에서 서로 납득할 만한 결과를 얻는 진행이다. 어느 한쪽만 일방적으로 이익을 얻는 것이 아니라, 양쪽이 각자의 목적에 따라 적절한 대가를 주고받는 것이 중요하다. 예를 들어서, 두 세력이 모두 비슷한 집을 나누어 가지거나, 아니면 한쪽이 실리를 얻는 대신 다른 쪽은 세력이나 두터움, 선수 등의 이익을 얻을 수도 있다.

=== 굳힘과 협공 ===
귀에 걸쳐 온 상대의 돌에 대응하는 대표적인 방법으로 굳힘과 협공이 있다.

<goban mode="player" move="5" from="0" to="5" autoplay="1000" loop="false" showcontrols="false" showmovenumber="true" view="A1:J10">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[dp]
;W[cn]
;B[fq]
;W[hq]
;B[cl]TR[fq]SQ[cl]
)
</goban>

위의 그림에서 세모(△)로 표시한 흑 3은 귀를 보강하여 실리를 확보하는 굳힘 성격의 수이고, 네모(□)로 표시한 흑 5는 백 2를 압박하는 협공이다.

굳힘은 자신의 귀를 안정시키고 실리를 확보하는 데 중점을 둔다. 반면 협공은 상대의 돌을 공격하면서 자신의 세력을 형성하거나 유리한 방향으로 발전하려는 목적을 가진다.

굳힘과 협공 중 어느 쪽이 좋은지는 주변의 배석에 따라 달라진다.

다음 그림을 보자.

<goban mode="player" move="8" from="0" to="8" autoplay="1000" loop="false" showmovenumber="true" showControls="false">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[pd]
;W[nc]
;B[qf]
;W[kc]
;B[dp]
;W[cn]
;B[cl]
;W[en]
)
</goban>

우상귀에서 흑 3은 귀를 굳히는 수이고, 백 4는 윗변으로 벌려 자신의 돌에 근거를 마련하는 수이다. 흑은 귀의 실리를 확보하고, 백은 변에서 발전할 수 있는 공간을 얻는다.

좌하귀에서는 흑 7로 백 6을 협공하자 백 8이 한 칸 뛰어 중앙 쪽으로 진출한다. 흑은 백의 돌을 압박하고, 백은 활동 공간을 넓히면서 이에 대응한다.

이처럼 굳힘과 협공은 서로 다른 목적을 가진다. 어느 쪽이 더 유리한지는 귀의 집뿐 아니라 변의 근거, 중앙으로의 발전 가능성, 돌의 안정 등을 함께 고려하여 판단해야 한다.

=== 실리와 세력의 균형 ===
정석에서 중요한 원리 중 하나는 실리와 세력의 균형이다.

<goban mode="player" view="M9:T19" move="8" from="0" to="8" autoplay="1000" loop="false" showmovenumber="true" showControls="false">
(;GM[1]FF[4]CA[UTF-8]SZ[19]
;B[pc]
;W[pe]
;B[qe]
;W[qf]
;B[qd]
;W[pf]
;B[nc]
;W[pj]
)
</goban>

위의 그림에서 흑은 우상귀의 실리를 확보하고, 백은 바깥쪽으로 세력을 형성하며 발전할 수 있는 공간을 얻는다.

== 좋은 정석 / 나쁜 정석 ==
정석은 기본적으로 양쪽이 합리적인 결과를 얻는 진행이지만, 모든 정석이 어떤 상황에서나 좋은 것은 아니다. 주변의 배석과 포석의 방향에 따라 같은 정석도 좋은 선택이 될 수도 있고 나쁜 선택이 될 수도 있다. 정석을 선택할 때는 다음의 원칙을 기억하는 것이 좋다. 다만 모든 수에는 예외가 존재한다는 것을 기억할것!

* '''자신의 돌이 막히는 진행을 경계한다.''' 외부와의 연결이 끊기고 근거도 없는 상태로 갇히면 이후 타개가 어려워질 수 있다.
* '''실리와 세력의 균형을 고려한다.''' 한쪽만 집을 확보하더라도 상대가 충분한 세력이나 두터움, 선수 등의 이익을 얻었다면 합리적인 진행이 될 수 있다.
* '''중복된 모양을 피한다.''' 이미 자신의 돌이 충분히 강한 곳에서 불필요하게 돌을 추가하면 효율이 떨어진다. 같은 곳에서 지나치게 많은 수를 교환하지 않도록 주의해야 한다.
* '''초반에는 작은 집보다 큰 자리를 우선한다.''' 안정된 귀에서 몇 집을 더 지키는 것보다 변의 큰 곳을 차지하거나 세력을 넓히는 편이 유리한 경우가 많다.
* '''불필요한 미생마를 만들지 않는다.''' 근거가 없는 돌을 여러 곳에 만들면 상대의 공격을 받기 쉽다. 자신의 돌을 안정시키면서도 효율적으로 발전하는 행마가 중요하다.
* '''2선으로 기는 수를 신중하게 선택한다.''' 2선은 집의 효율이 낮으므로 초반부터 불필요하게 기는 것은 좋지 않다. 다만 돌을 살리거나 상대의 약점을 이용하는 경우에는 필요한 수가 될 수 있다.
* '''상대의 강한 돌에 무리하게 붙지 않는다.''' 강한 돌에 접근하면 상대의 모양을 더욱 단단하게 만들면서 자신의 돌만 약해질 수 있다. 다만 붙이는 수가 유효한 수단이 되는 경우도 있으므로 주변 상황을 고려해야 한다.
* '''기본적인 행마를 익힌다.''' 한 칸 뜀은 돌을 안정적으로 움직이는 대표적인 행마이다. 정석에서도 한 칸 뜀, 날일자, 눈목자, 벌림 등의 기본적인 행마를 이해하는 것이 중요하다.

무엇보다 '''정석은 외우는 것이 아니라 상황에 맞게 선택하는 것'''이라는 점을 기억해야 한다. 정석의 형태 자체가 좋더라도 주변의 돌과 어울리지 않으면 전체적으로 불리한 결과가 될 수 있다.

== 정석 분류 ==
* [[화점 정석]]
* [[소목 정석]]
* [[삼삼 정석]]

분류:바둑

Ahn9807 — Fri, 30 Oct 2026 14:12:58 GMT

← 이전 판		2026년 10월 30일 (금) 14:12 판
2번째 줄:		2번째 줄:

	== 상위 분류 (8개) ==		== 상위 분류 (8개) ==
	~~[[분류:바둑]]~~
	* [[바둑 일반]]		* [[바둑 일반]]
	* [[포석]]		* [[포석]]

분류:바둑

Ahn9807 — Fri, 30 Oct 2026 01:54:11 GMT

새 문서: 분류:취미 == 상위 분류 (8개) == 분류:바둑 * 바둑 일반 * 포석 * 정석 * 행마 * 중반전 * 사활 * 끝내기 * '''바둑 일반 지식''': 바둑 일반 지식/바둑이란, 바둑 일반 지식/바둑의 규칙, 바둑 일반 지식/한 판의 과정, 바둑 일반 지식/대국의 예절, 바둑 일반 지식/바둑의 한자어, 바둑 일반 지식/바둑 용어집 * '''바둑 포석''': 바둑 포석/3-3점 포석,...

새 문서

[[분류:취미]]

== 상위 분류 (8개) ==
[[분류:바둑]]
* [[바둑 일반]]
* [[포석]]
* [[정석]]
* [[행마]]
* [[중반전]]
* [[사활]]
* [[끝내기]]

* '''바둑 일반 지식''': 바둑 일반 지식/바둑이란, 바둑 일반 지식/바둑의 규칙, 바둑 일반 지식/한 판의 과정, 바둑 일반 지식/대국의 예절, 바둑 일반 지식/바둑의 한자어, 바둑 일반 지식/바둑 용어집
* '''바둑 포석''': 바둑 포석/3-3점 포석, 바둑 포석/4-4점 포석, 바둑 포석/4-3점 포석, 바둑 포석/3-4점 포석, 바둑 포석/2-2점 포석, 바둑 포석/1점 포석
* '''바둑 행마''': 바둑 행마/연결, 바둑 행마/끊기, 바둑 행마/달아나기, 바둑 행마/꿩기, 바둑 행마/젓하기, 바둑 행마/후고, 바둑 행마/반삼각, 바둑 행마/이단 뛰기, 바둑 행마/사다리
* '''바둑 중반전''': 바둑 중반전/영토와 전투, 바둑 중반전/두 칸 벌림, 바둑 중반전/수읽기, 바둑 중반전/사석, 바둑 중반전/패의 종류, 바둑 중반전/중반전 전술
* '''바둑 사활''': 바둑 사활/사활의 의미, 바둑 사활/삶의 조건, 바둑 사활/죽음의 조건, 바둑 사활/쌍안, 바둑 사활/독립집, 바둑 사활/옥집, 바둑 사활/공배, 바둑 사활/사활 문제
* '''바둑 끝내기''': 바둑 끝내기/끝내기의 의미, 바둑 끝내기/계산, 바둑 끝내기/컴펜세이션, 바둑 끝내기/코, 바둑 끝내기/작은 끝내기, 바둑 끝내기/큰 끝내기, 바둑 끝내기/끝내기 순서
* '''바둑 정석''': 바둑 정석/정석이란, 바둑 정석/모서리 정석, 바둑 정석/사선 정석, 바둑 정석/1선~5선, 바둑 정석/1-1, 바둑 정석/3-3, 바둑 정석/4-4, 바둑 정석/4-3, 바둑 정석/3-4, 바둑 정석/2-2, 바둑 정석/1-2, 바둑 정석/1-3

화점 정석

Ahn9807 — Wed, 28 Oct 2026 16:08:38 GMT

새 문서: 분류:바둑

새 문서

[[:분류:바둑]]

MTSan: A Feasible and Practical Memory Sanitizer for Fuzzing COTS Binaries

Ahn9807 — Mon, 19 Oct 2026 10:39:07 GMT

← 이전 판		2026년 10월 19일 (월) 10:39 판
(같은 사용자의 중간 판 하나는 보이지 않습니다)
20번째 줄:		20번째 줄:

	== Design ==		== Design ==
	# ~~'''~~Object pointer identification~~'''~~: Heap은 allocator 호출을 관찰하고, stack은 SP 및 SP에서 유도된 값, global은 해당 메모리 영역의 주소에서 raw pointer를 식별한다. Pointer arithmetic으로 파생된 포인터도 추적한다. Stack 객체 수명은 해당 stack frame의 할당부터 반환까지, global 객체 수명은 process 수명으로 모델링한다. 이 모델은 소스 수준의 세밀한 lexical lifetime과는 구분해야 한다.		# Object pointer identification: Heap은 allocator 호출을 관찰하고, stack은 SP 및 SP에서 유도된 값, global은 해당 메모리 영역의 주소에서 raw pointer를 식별한다. Pointer arithmetic으로 파생된 포인터도 추적한다. Stack 객체 수명은 해당 stack frame의 할당부터 반환까지, global 객체 수명은 process 수명으로 모델링한다. 이 모델은 소스 수준의 세밀한 lexical lifetime과는 구분해야 한다.
	# ~~'''~~Progressive object recovery~~'''~~: 함수 내 value-set analysis로 초기 접근 범위를 계산하고, 실행 중 raw·derived pointer의 접근을 관찰해 객체 범위를 보완한다. 예를 들어 시작 주소 A에서 8 byte를 읽고 A+24에서 8 byte를 읽으면 중간 간격을 포함한 [A, A+32)를 같은 객체로 추정한다. 이후 실행에서 더 먼 접근이 나오면 경계를 확장하고, 다른 객체와 겹치면 잠재적 위반으로 처리한다. Stack canary·saved return address 등 알려진 구조도 deterministic boundary 식별에 활용한다. 관찰된 범위가 실제 선언 크기를 보장하지는 않는다.		# Progressive object recovery: 함수 내 value-set analysis로 초기 접근 범위를 계산하고, 실행 중 raw·derived pointer의 접근을 관찰해 객체 범위를 보완한다. 예를 들어 시작 주소 A에서 8 byte를 읽고 A+24에서 8 byte를 읽으면 중간 간격을 포함한 [A, A+32)를 같은 객체로 추정한다. 이후 실행에서 더 먼 접근이 나오면 경계를 확장하고, 다른 객체와 겹치면 잠재적 위반으로 처리한다. Stack canary·saved return address 등 알려진 구조도 deterministic boundary 식별에 활용한다. 관찰된 범위가 실제 선언 크기를 보장하지는 않는다.
	# ~~'''~~MTE 기반 tagging~~'''~~: MTE는 포인터의 4-bit tag와 16-byte granule의 memory tag를 비교한다. MTSan은 이웃 객체가 서로 다른 tag를 갖도록 하고, 할당 시 포인터와 메모리에 같은 tag를 부여하며 해제 시 tag를 바꾸어 stale pointer 접근을 드러낸다. Stack·global tag는 갱신 가능한 metadata region에 저장한다. Tag가 포인터 비교를 교란하지 않도록 필요한 명령을 수정한다. 작은 인접 객체는 compound object로 묶으며, 그 내부의 overflow는 탐지하지 못한다.		# MTE 기반 tagging: MTE는 포인터의 4-bit tag와 16-byte granule의 memory tag를 비교한다. MTSan은 이웃 객체가 서로 다른 tag를 갖도록 하고, 할당 시 포인터와 메모리에 같은 tag를 부여하며 해제 시 tag를 바꾸어 stale pointer 접근을 드러낸다. Stack·global tag는 갱신 가능한 metadata region에 저장한다. Tag가 포인터 비교를 교란하지 않도록 필요한 명령을 수정한다. 작은 인접 객체는 compound object로 묶으며, 그 내부의 overflow는 탐지하지 못한다.
	# ~~'''~~Adaptive sanitization과 RRR~~'''~~: Deterministic property에 근거한 위반은 critical로 분류해 현재 실행을 종료하고 보고한다. Presumptive boundary 위반은 non-critical로 분류한다. Record 단계에서 입력과 metadata 사본을 저장하고, Resume 단계에서 관련 객체를 병합해 동일 경고가 탐색을 반복 중단하지 않게 한다. Regression 단계에서는 기록한 입력을 fuzzing queue에 넣어 더 진행된 입력이 확실한 경계나 수명을 위반하도록 유도한다. 병합은 오탐을 줄이지만 실제 객체 간 경계도 약화할 수 있으므로 후속 탐색이 중요하다.		# Adaptive sanitization과 RRR: Deterministic property에 근거한 위반은 critical로 분류해 현재 실행을 종료하고 보고한다. Presumptive boundary 위반은 non-critical로 분류한다. Record 단계에서 입력과 metadata 사본을 저장하고, Resume 단계에서 관련 객체를 병합해 동일 경고가 탐색을 반복 중단하지 않게 한다. Regression 단계에서는 기록한 입력을 fuzzing queue에 넣어 더 진행된 입력이 확실한 경계나 수명을 위반하도록 유도한다. 병합은 오탐을 줄이지만 실제 객체 간 경계도 약화할 수 있으므로 후속 탐색이 중요하다.
	# ~~'''~~Rewriting 및 최적화~~'''~~: Analyzer는 angr·IDA Pro, rewriter는 Capstone·Keystone을 사용한다. 정적 계측 코드와 실행 중 필요한 명령 갱신을 결합해 AFL++ fork server와 통합한다. 초기 seed dry run에서 non-critical 위반을 정상 동작으로 받아들이는 two-stage fuzzing, 안전하다고 판정한 고정 주소 접근의 계측 축소, 안전 영역의 tag 예약으로 비용을 줄인다. 첫 input read 이전 접근도 정상으로 신뢰하므로 탐지 목표는 입력으로 유발되는 오류에 맞춰진다.		# Rewriting 및 최적화: Analyzer는 angr·IDA Pro, rewriter는 Capstone·Keystone을 사용한다. 정적 계측 코드와 실행 중 필요한 명령 갱신을 결합해 AFL++ fork server와 통합한다. 초기 seed dry run에서 non-critical 위반을 정상 동작으로 받아들이는 two-stage fuzzing, 안전하다고 판정한 고정 주소 접근의 계측 축소, 안전 영역의 tag 예약으로 비용을 줄인다. 첫 input read 이전 접근도 정상으로 신뢰하므로 탐지 목표는 입력으로 유발되는 오류에 맞춰진다.

	== Result ==		== Result ==
38번째 줄:		38번째 줄:

	=== 탐지 효과 ===		=== 탐지 효과 ===
	* ~~'''~~Juliet v1.3~~'''~~: MTSan의 전체 false negative rate는 24.17%이며, ASan-Retrowrite 대비 false negative 개수가 38.3% 감소했다. 이 실험에서는 비교 sanitizer 모두 false positive가 0건이었다(Table 2). 이는 실제 프로그램에서 경계 추론 오탐이 없다는 뜻은 아니다.		* Juliet v1.3: MTSan의 전체 false negative rate는 24.17%이며, ASan-Retrowrite 대비 false negative 개수가 38.3% 감소했다. 이 실험에서는 비교 sanitizer 모두 false positive가 0건이었다(Table 2). 이는 실제 프로그램에서 경계 추론 오탐이 없다는 뜻은 아니다.
	* ~~'''~~실제 취약점 재현~~'''~~: 27개 취약점으로 구성된 데이터셋에서 stack·global 취약점 15개 중 13개를 탐지했다. 비교한 기존 binary sanitizer들은 해당 stack·global 취약점을 탐지하지 못했다. Heap 취약점 12개 중 5개에서는 MTSan이 가장 많은 PoC를 탐지했다(Section 7.2, Table 3). 취약점 개수와 한 취약점에 대한 PoC 개수는 별도 지표다.		* 실제 취약점 재현: 27개 취약점으로 구성된 데이터셋에서 stack·global 취약점 15개 중 13개를 탐지했다. 비교한 기존 binary sanitizer들은 해당 stack·global 취약점을 탐지하지 못했다. Heap 취약점 12개 중 5개에서는 MTSan이 가장 많은 PoC를 탐지했다(Section 7.2, Table 3). 취약점 개수와 한 취약점에 대한 PoC 개수는 별도 지표다.
	* ~~'''~~Fuzzing~~'''~~: Benchmark별 24시간 실험을 3회 수행했다. LibMTE 기반 MTSan은 20개 버그를 보고했고, QASan은 17개, ASan-Retrowrite는 14개를 보고했다. 네 개는 MTSan을 사용한 fuzzing에서만 발견되었다(Table 5). 이 숫자는 실험 내 발견 결과이며, 모두 새로운 취약점이라는 주장은 아니다.		* Fuzzing: Benchmark별 24시간 실험을 3회 수행했다. LibMTE 기반 MTSan은 20개 버그를 보고했고, QASan은 17개, ASan-Retrowrite는 14개를 보고했다. 네 개는 MTSan을 사용한 fuzzing에서만 발견되었다(Table 5). 이 숫자는 실험 내 발견 결과이며, 모두 새로운 취약점이라는 주장은 아니다.
	* ~~'''~~속도와 ablation~~'''~~: Analog 설정의 평균 실행 수는 AFL++ Qemu보다 58.07% 높았지만, 이는 실제 MTE의 처리량 측정이 아니다. LibMTE 기반 MTSan에서 object recovery를 끈 설정은 16개, RRR을 끈 설정도 16개 버그를 보고하여 전체 구성의 20개보다 적었다. RRR 자체의 실행 비용은 3% 미만으로 보고되었다.		* 속도와 ablation: Analog 설정의 평균 실행 수는 AFL++ Qemu보다 58.07% 높았지만, 이는 실제 MTE의 처리량 측정이 아니다. LibMTE 기반 MTSan에서 object recovery를 끈 설정은 16개, RRR을 끈 설정도 16개 버그를 보고하여 전체 구성의 20개보다 적었다. RRR 자체의 실행 비용은 3% 미만으로 보고되었다.
	* ~~'''~~불확실성 관리 효과~~'''~~: RRR은 non-critical violation 일곱 개를 critical violation으로 이어지게 했으며, critical violation 네 개는 RRR 과정에서만 관찰되었다. 한 개는 더 빨리 발견했지만 세 경우에는 critical violation이 먼저 발생해, RRR이 항상 time-to-discovery를 줄이지는 않았다. 객체 병합·갱신 대부분은 첫 한 시간에 집중되었다(Section 7.4.3).		* 불확실성 관리 효과: RRR은 non-critical violation 일곱 개를 critical violation으로 이어지게 했으며, critical violation 네 개는 RRR 과정에서만 관찰되었다. 한 개는 더 빨리 발견했지만 세 경우에는 critical violation이 먼저 발생해, RRR이 항상 time-to-discovery를 줄이지는 않았다. 객체 병합·갱신 대부분은 첫 한 시간에 집중되었다(Section 7.4.3).

	== Contribution ==		== Contribution ==
51번째 줄:		51번째 줄:

	== [[Conclusion]] ==		== [[Conclusion]] ==
	MTSan의 핵심은 binary의 객체 정보를 완벽히 복원하는 데 있지 않고, 불완전한 경계 정보를 fuzzing 과정에서 개선하며 그 불확실성에 맞게 오류를 처리하는 데 있다. 이를 MTE와 결합하여 기존 heap 중심 binary sanitizer가 놓치던 stack·global 오류를 탐지하고, 소프트웨어 구현으로도 비교 실험에서 더 많은 버그를 발견했다. ~~'''~~객체 복원과 sanitization을 공동 설계하고, 불확실한 경고를 후속 탐색의 출발점으로 ~~사용한다'''는~~ 원리를 제시하였다.		MTSan의 핵심은 binary의 객체 정보를 완벽히 복원하는 데 있지 않고, 불완전한 경계 정보를 fuzzing 과정에서 개선하며 그 불확실성에 맞게 오류를 처리하는 데 있다. 이를 MTE와 결합하여 기존 heap 중심 binary sanitizer가 놓치던 stack·global 오류를 탐지하고, 소프트웨어 구현으로도 비교 실험에서 더 많은 버그를 발견했다. 객체 복원과 sanitization을 공동 설계하고, 불확실한 경고를 후속 탐색의 출발점으로 사용한다는 원리를 제시하였다.

	[[분류: USENIX Security]]		[[분류:USENIX Security]]

MTSan: A Feasible and Practical Memory Sanitizer for Fuzzing COTS Binaries

Noribot — Mon, 19 Oct 2026 10:05:48 GMT

Nori: update draft.wikitext

새 문서

{{Paper
|title=MTSan: A Feasible and Practical Memory Sanitizer for Fuzzing COTS Binaries
|author=Xingman Chen, Yinghao Shi, Zheyu Jiang, Yuan Li, Ruoyu Wang, Haixin Duan, Haoyu Wang, Chao Zhang
|conference=32nd USENIX Security Symposium
|year=2023
}}

== 개요 ==
소스 코드가 없는 COTS binary에서 객체의 경계와 수명을 어떻게 복원하고, 이를 [[Memory tagging]]과 결합하여 heap뿐 아니라 stack·global 영역의 메모리 오류까지 fuzzing 중 탐지할 수 있을까? MTSan은 객체 정보를 실행 간 점진적으로 보완하는 progressive object recovery, 불확실한 위반을 후속 fuzzing으로 검증하는 adaptive sanitization, ARM [[Memory Tagging Extension]](MTE)을 결합한 binary memory sanitizer이다. 정확한 type reconstruction 대신 오류 탐지에 필요한 객체 경계와 수명에 집중하는 보안 시스템 설계 논문이다.

== Motivation ==
[[Fuzzing]]에서 crash만 관찰하면 다른 유효한 객체를 덮어쓰거나 해제된 영역을 접근해도 즉시 종료되지 않는 메모리 오류를 놓친다. [[AddressSanitizer]] 같은 sanitizer는 이러한 오류를 조기에 드러내지만, 소스 기반 계측을 COTS binary에 그대로 적용하기는 어렵다. 컴파일 과정에서 객체의 type·boundary 정보가 사라지고, binary rewriting만으로 stack과 global 객체 사이에 redzone을 삽입하기도 어렵기 때문이다.

기존 binary sanitizer는 heap 중심의 탐지 범위와 높은 비용 사이에서 제약을 갖는다. Valgrind와 QASan은 동적 계측·에뮬레이션 비용이 크고, ASan-Retrowrite는 정적 rewriting으로 실행 비용을 낮추지만 메모리 비용이 남는다. Fuzzing에서는 실행당 비용이 증가하면 같은 시간에 탐색할 입력 수가 줄어들므로, 탐지 범위와 처리량을 함께 개선해야 한다.

== Main Idea ==
핵심은 객체 정보의 확실성을 구분하는 것이다. Heap allocation 크기와 allocation/deallocation 시점은 관찰 가능한 정보지만, stack·global 객체의 경계는 제한된 접근만으로 추정해야 한다. MTSan은 이를 각각 deterministic property와 presumptive property로 구분하고, fuzzing 실행들이 관찰한 포인터와 접근 범위를 모아 추정 경계를 갱신한다.

복원된 객체에는 포인터 tag와 memory tag를 부여해 spatial·temporal violation을 검사한다. Deterministic property를 위반하면 critical error로 보고하지만, presumptive boundary 위반은 실제 버그와 경계 추론 오류를 구별하기 어렵다. 이 경우 입력을 기록하고 관련 객체를 병합하여 탐색을 계속한 뒤, 기록한 입력에서 출발하는 regression fuzzing으로 critical violation을 유도한다. 이는 불확실한 경고를 확정 버그로 취급하기보다 추가 탐색의 단서로 사용하는 접근이다.

== Design ==
# '''Object pointer identification''': Heap은 allocator 호출을 관찰하고, stack은 SP 및 SP에서 유도된 값, global은 해당 메모리 영역의 주소에서 raw pointer를 식별한다. Pointer arithmetic으로 파생된 포인터도 추적한다. Stack 객체 수명은 해당 stack frame의 할당부터 반환까지, global 객체 수명은 process 수명으로 모델링한다. 이 모델은 소스 수준의 세밀한 lexical lifetime과는 구분해야 한다.
# '''Progressive object recovery''': 함수 내 value-set analysis로 초기 접근 범위를 계산하고, 실행 중 raw·derived pointer의 접근을 관찰해 객체 범위를 보완한다. 예를 들어 시작 주소 A에서 8 byte를 읽고 A+24에서 8 byte를 읽으면 중간 간격을 포함한 [A, A+32)를 같은 객체로 추정한다. 이후 실행에서 더 먼 접근이 나오면 경계를 확장하고, 다른 객체와 겹치면 잠재적 위반으로 처리한다. Stack canary·saved return address 등 알려진 구조도 deterministic boundary 식별에 활용한다. 관찰된 범위가 실제 선언 크기를 보장하지는 않는다.
# '''MTE 기반 tagging''': MTE는 포인터의 4-bit tag와 16-byte granule의 memory tag를 비교한다. MTSan은 이웃 객체가 서로 다른 tag를 갖도록 하고, 할당 시 포인터와 메모리에 같은 tag를 부여하며 해제 시 tag를 바꾸어 stale pointer 접근을 드러낸다. Stack·global tag는 갱신 가능한 metadata region에 저장한다. Tag가 포인터 비교를 교란하지 않도록 필요한 명령을 수정한다. 작은 인접 객체는 compound object로 묶으며, 그 내부의 overflow는 탐지하지 못한다.
# '''Adaptive sanitization과 RRR''': Deterministic property에 근거한 위반은 critical로 분류해 현재 실행을 종료하고 보고한다. Presumptive boundary 위반은 non-critical로 분류한다. Record 단계에서 입력과 metadata 사본을 저장하고, Resume 단계에서 관련 객체를 병합해 동일 경고가 탐색을 반복 중단하지 않게 한다. Regression 단계에서는 기록한 입력을 fuzzing queue에 넣어 더 진행된 입력이 확실한 경계나 수명을 위반하도록 유도한다. 병합은 오탐을 줄이지만 실제 객체 간 경계도 약화할 수 있으므로 후속 탐색이 중요하다.
# '''Rewriting 및 최적화''': Analyzer는 angr·IDA Pro, rewriter는 Capstone·Keystone을 사용한다. 정적 계측 코드와 실행 중 필요한 명령 갱신을 결합해 AFL++ fork server와 통합한다. 초기 seed dry run에서 non-critical 위반을 정상 동작으로 받아들이는 two-stage fuzzing, 안전하다고 판정한 고정 주소 접근의 계측 축소, 안전 영역의 tag 예약으로 비용을 줄인다. 첫 input read 이전 접근도 정상으로 신뢰하므로 탐지 목표는 입력으로 유발되는 오류에 맞춰진다.

== Result ==
{| class="wikitable"
! 설정 !! SPEC CPU 2017 C benchmark 실행 시간 배율 !! 메모리 사용 배율
|-
| MTSan (instruction analog) || 1.82× || 1.58×
|-
| MTSan (libMTE) || 4.01× || 2.10×
|-
| ASan-Retrowrite || 2.57× || 7.30×
|}

=== 탐지 효과 ===
* '''Juliet v1.3''': MTSan의 전체 false negative rate는 24.17%이며, ASan-Retrowrite 대비 false negative 개수가 38.3% 감소했다. 이 실험에서는 비교 sanitizer 모두 false positive가 0건이었다(Table 2). 이는 실제 프로그램에서 경계 추론 오탐이 없다는 뜻은 아니다.
* '''실제 취약점 재현''': 27개 취약점으로 구성된 데이터셋에서 stack·global 취약점 15개 중 13개를 탐지했다. 비교한 기존 binary sanitizer들은 해당 stack·global 취약점을 탐지하지 못했다. Heap 취약점 12개 중 5개에서는 MTSan이 가장 많은 PoC를 탐지했다(Section 7.2, Table 3). 취약점 개수와 한 취약점에 대한 PoC 개수는 별도 지표다.
* '''Fuzzing''': Benchmark별 24시간 실험을 3회 수행했다. LibMTE 기반 MTSan은 20개 버그를 보고했고, QASan은 17개, ASan-Retrowrite는 14개를 보고했다. 네 개는 MTSan을 사용한 fuzzing에서만 발견되었다(Table 5). 이 숫자는 실험 내 발견 결과이며, 모두 새로운 취약점이라는 주장은 아니다.
* '''속도와 ablation''': Analog 설정의 평균 실행 수는 AFL++ Qemu보다 58.07% 높았지만, 이는 실제 MTE의 처리량 측정이 아니다. LibMTE 기반 MTSan에서 object recovery를 끈 설정은 16개, RRR을 끈 설정도 16개 버그를 보고하여 전체 구성의 20개보다 적었다. RRR 자체의 실행 비용은 3% 미만으로 보고되었다.
* '''불확실성 관리 효과''': RRR은 non-critical violation 일곱 개를 critical violation으로 이어지게 했으며, critical violation 네 개는 RRR 과정에서만 관찰되었다. 한 개는 더 빨리 발견했지만 세 경우에는 critical violation이 먼저 발생해, RRR이 항상 time-to-discovery를 줄이지는 않았다. 객체 병합·갱신 대부분은 첫 한 시간에 집중되었다(Section 7.4.3).

== Contribution ==
# Binary에서 완전한 type inference 대신 경계와 수명에 집중하고, fuzzing 실행 간 정보를 통합하는 progressive object recovery를 제안했다.
# 복원 정보의 확실성에 따라 오류 대응을 나누고, non-critical violation을 후속 탐색으로 검증하는 Record–Resume–Regression 정책을 제안했다.
# 객체 복원·binary rewriting·MTE tagging을 결합하여 heap·stack·global 영역을 다루는 sanitizer를 구현하고, MTE가 없는 환경을 위한 libMTE도 제공했다.
# 합성 테스트, 실제 취약점 PoC, 반복 fuzzing, 성능 평가와 ablation을 통해 탐지 범위와 실행 비용의 tradeoff를 분석했다.

== [[Conclusion]] ==
MTSan의 핵심은 binary의 객체 정보를 완벽히 복원하는 데 있지 않고, 불완전한 경계 정보를 fuzzing 과정에서 개선하며 그 불확실성에 맞게 오류를 처리하는 데 있다. 이를 MTE와 결합하여 기존 heap 중심 binary sanitizer가 놓치던 stack·global 오류를 탐지하고, 소프트웨어 구현으로도 비교 실험에서 더 많은 버그를 발견했다. '''객체 복원과 sanitization을 공동 설계하고, 불확실한 경고를 후속 탐색의 출발점으로 사용한다'''는 원리를 제시하였다.

[[분류: USENIX Security]]

CMASan: Custom Memory Allocator-aware Address Sanitizer

Ahn9807 — Mon, 19 Oct 2026 02:57:41 GMT

차이 보기

CMASan: Custom Memory Allocator-aware Address Sanitizer

Noribot — Sat, 17 Oct 2026 08:08:02 GMT

Nori: update draft.wikitext

새 문서

{{Paper
|title=CMASan: Custom Memory Allocator-aware Address Sanitizer
|author=Junwha Hong, Wonil Jang, Mijung Kim, Lei Yu, Yonghwi Kwon, Yuseok Jeon
|conference=IEEE Symposium on Security and Privacy (S&P)
|year=2025
}}

== 개요 ==
이 논문은 [[Custom memory allocator]](CMA)가 할당한 객체에서 [[AddressSanitizer]](ASan)가 왜 메모리 버그를 놓치며, CMA를 표준 allocator로 교체하지 않고 객체의 경계와 수명을 추적하여 그 공백을 어떻게 줄일 수 있는지를 다룬다. CMASan은 CMA API의 반자동 식별, redzone 계측, 객체 메타데이터, instance별 quarantine 및 clear 처리를 결합한 보안·디버깅 도구이다.

== Motivation ==
CMA는 cache 활용, 메모리 효율, 보안 등의 목적으로 사용된다. 논문이 GitHub star 순 상위 C/C++ 애플리케이션 100개를 조사한 결과, 44개에서 78개의 CMA를 발견했다. 문제는 ASan이 표준 allocator가 제공하는 객체 경계와 free를 추적하므로, 그 위에서 CMA가 정의한 더 작은 객체와 별도의 수명을 알지 못한다는 것이다.

* '''Arena 패턴''': 큰 chunk를 받아 작은 객체로 분할한다. ASan은 큰 chunk 외곽만 보호하므로 내부 객체 사이의 [[Buffer overflow]]를 놓칠 수 있다. 조사된 CMA의 69%가 이 패턴을 사용했다.
* '''Recycler 패턴''': 반환된 객체를 내부 free-list 등에 저장하고 재사용한다. 표준 free가 호출되지 않으면 ASan은 CMA 수준의 해제를 인식하지 못해 [[Use-after-free]](UAF)와 [[Double free]](DF)를 놓친다. 조사된 CMA의 45%가 이 패턴을 사용했으며 Arena와 중첩될 수 있다.

기존 Shim은 CMA를 표준 allocator로 대체하지만, 주소를 유지하는 in-place realloc이나 여러 객체를 한꺼번에 무효화하는 clear를 단순히 realloc/free에 대응시키기 어렵다. Manual poisoning API는 CMA를 유지할 수 있으나, 개발자가 객체 경계·수명에 맞추어 poisoning을 삽입하고 redzone 공간 및 재사용 지연을 구현해야 한다. 조사에서는 Shim을 사용하는 애플리케이션이 10개였지만 그중 5개는 일부 CMA만 지원했고, manual poisoning API를 사용하는 애플리케이션은 3개였다.

== Importance ==
이 논문의 중요한 관점은 '''메모리 접근 검사 코드가 존재하는 것과 올바른 객체 경계·수명을 검사하는 것은 별개'''라는 점이다. ASan이 load/store를 검사하더라도 CMA 내부 객체의 경계와 해제가 shadow memory에 반영되지 않으면 오류를 발견할 수 없다.

CMASan은 기존 테스트 입력을 유지하면서 allocator에 대한 관측을 개선하는 접근이다. SQLite3와 PHP의 기존 테스트가 이미 실행하던 버그를 각각 9년, 2년 만에 발견했다는 결과는 입력 생성뿐 아니라 sanitizer의 객체 모델도 탐지 능력을 좌우한다는 근거가 된다. 또한 정확한 CMA 지원에는 alloc/free 외에 clear, size query, object collection 같은 보조 API의 의미가 필요함을 보여준다.

== Main Idea ==
핵심 아이디어는 '''CMA의 내부 할당기를 유지하면서 CMA가 애플리케이션에 제공하는 객체 단위의 경계와 수명을 ASan에 연결'''하는 것이다. API를 식별한 뒤 요청 크기를 늘려 redzone 공간을 확보하고, 할당·해제에 맞추어 [[Shadow memory]]를 갱신하며, 표준 allocator의 메타데이터와 별개로 CMA 객체 정보를 관리한다.

Temporal bug는 해제를 인식하는 것만으로 충분하지 않다. 객체가 즉시 재사용되면 오래된 포인터의 접근도 정상 객체 접근처럼 보이므로, instance별로 실제 free 요청을 지연하여 poisoning이 유지되는 시간을 늘린다. clear에는 해당 instance의 할당 객체 집합을 이용한다. 이때 CMA 내부의 합법적인 메타데이터 접근과 중첩 호출은 별도로 처리하여 오탐을 줄인다.

== Design ==
# '''CMA API 식별과 반자동 분류''': CodeQL의 함수 이름·반환 포인터·size 인자 휴리스틱을 확장하고, size가 pointer arithmetic이나 내부 메타데이터 비교에 쓰이는지를 확인하여 후보를 추린다. 같은 source/header module의 함수를 family로 묶고, 규칙과 함수 본문을 사람이 검토하여 alloc/calloc/realloc/free/clear 및 보조 API, size·object·instance 인자를 분류한다. 평가에서 애플리케이션당 약 10분의 일회성 수작업이 필요했다. 소스의 수동 수정은 요구하지 않지만 API 인식 전체가 자동인 것은 아니다.
# '''객체 경계와 수명 계측''': alloc의 요청 크기에 redzone 크기를 추가하고 반환 객체 오른쪽을 poison한다. calloc/typed alloc은 개수와 granularity를 고려한다. 왼쪽에는 CMA 메타데이터가 있을 수 있어 별도의 redzone을 넣지 않으며, 인접 객체에서는 앞 객체의 오른쪽 redzone이 경계를 제공한다. free에서는 원래 객체 크기만큼 poison하고, 이미 FREED 상태이며 CMA ID가 같으면 DF를 보고한다. realloc은 반환 주소를 비교하여 제자리 resizing과 이동을 구분하고, 이동한 경우 이전 객체도 poison한다. redzone 확보를 위한 크기 증가는 CMA의 용량·최적화 판단에 영향을 줄 수 있다.
# '''Two-level 객체 메타데이터''': 주소로 객체 시작점, size, redzone size, 할당 상태, CMA ID, alloc/free trace를 찾는다. CMA가 좁은 주소 범위를 반복 사용하는 특성을 이용하여 2차 테이블을 필요할 때 할당한다. 구현의 1차 테이블은 64MB, 각 2차 테이블은 128MB이다. arena가 반환되면 관련 메타데이터를 제거하고, 재할당이 기존 기록과 겹치면 새 객체 영역은 갱신하되 겹치지 않는 freed 영역의 기록은 남겨 오래된 객체 접근을 추적한다.
# '''Instance별 free-delaying quarantine''': CMA free를 즉시 실행하지 않고 객체를 poison한 뒤 요청을 FIFO에 보관한다. 한도에 도달하면 오래된 요청을 해당 CMA에 전달한다. 서로 다른 CMA instance의 요청이 섞이지 않도록 분리하며, 기본 한도는 256KB와 8,192개 객체이다. 객체 재사용을 늦춰 UAF/DF 탐지 창을 늘리는 대신 메모리 사용량과 실제 해제 시점을 바꾼다. 내용 보존이 필요한 realloc에는 이 free 지연을 적용하지 않는다.
# '''Instance별 allocation zone과 clear 처리''': 할당 객체를 instance별로 기록하고 clear 호출 시 해당 집합을 freed로 표시한다. 표준 free가 호출되지 않는 bulk reset도 추적할 수 있지만, 기본적으로 최근 10,000개 객체까지만 기록하므로 무제한 추적은 아니다.
# '''네 가지 오탐 회피''': CMA 내부 동작과 계측 사이의 충돌을 아래 방법으로 처리한다. 정확도 개선에는 검사 억제와 추가 runtime 비용이라는 대가가 있다.

; Call stack-based suppression
: 오류 검출 시 stack에 CMA 관련 함수가 있으면 보고를 억제하여, freed 객체에 저장된 내부 메타데이터 접근 등을 허용한다. 공용 함수를 통째로 검사에서 제외하는 ignore list보다 실행 문맥을 구분하지만 CMA 내부 버그도 가릴 수 있다.
; Call stack-based activation
: 중첩된 CMA API에서는 가장 바깥 호출의 계측만 활성화한다. realloc 내부 alloc/free를 중복 처리하여 redzone을 거듭 늘리거나 DF를 잘못 보고하는 문제를 막는다.
; Size leakage avoidance
: size query API가 redzone을 포함한 확장 크기를 노출하지 않도록 원래 애플리케이션이 요청한 크기를 반환한다.
; Object-collecting API handling
: GC 등 별도의 수거 API 호출 시 해당 quarantine을 비워, 수거된 객체를 나중에 다시 free하는 충돌을 피한다.

구현은 LLVM/ASan 15.0.6과 CodeQL 2.18.2를 기반으로 하며 약 3,000 LoC이다. CMA API가 ASan pass 이전에 inline되어 계측 지점이 사라지는 것을 막기 위해 Clang AST에서 inlining을 금지한다. Typed alloc의 granularity 추론에는 pointer type 정보가 필요하여 LLVM 15의 opaque pointer 기능을 끈 구성을 사용한다. Runtime에는 binary/library에서 CMA 함수 주소를 얻고 dlopen도 추적하여 call stack 판정에 사용한다.

== Result ==
=== 평가 범위와 적용 비용 ===
성능·coverage·오탐 평가는 C와 C++ 각각 GitHub star 상위 30개 repository 중 Clang 15.0.6으로 빌드 가능하고 CMA 및 workload가 있는 12개를 대상으로 했다. 환경은 Intel Core i9-13900KF, RAM 128GB, RTX 4090, Ubuntu 22.04.1이며, ASan과 CMASan 모두 -O2, -fno-omit-frame-pointer, -fno-optimize-sibling-calls를 사용했다. API 분류에 드는 사람의 작업은 애플리케이션당 약 10분이었다(§5.1–5.2).

Table 1에서 ncnn의 CMA 객체 관련 load/store check는 전체의 87.15%, Redis는 42.93%, PHP는 30.02%였다. 이는 ASan이 검사 명령을 전혀 실행하지 않는다는 뜻이 아니라, 그 검사에 필요한 CMA 내부 객체 경계·수명 정보를 기본 ASan이 반영하지 못한다는 뜻으로 이해해야 한다.

=== 비용 ===
{| class="wikitable"
|+ ASan 대비 CMASan의 추가 오버헤드(Table 2)
! 대상 !! 실행시간 증가 !! 메모리 증가
|-
| 12개 애플리케이션 평균 || 9.63% || 14.83%
|-
| PHP || 21.76% || 7.85%
|-
| TensorFlow || 28.80% || 9.80%
|-
| ncnn || 22.44% || 99.09%
|-
| Redis || 9.50% || 33.46%
|}

메모리는 peak RSS를 기준으로 평가했으며, Appendix C.1은 workload 실행 중 각 process의 peak RSS를 합산한 값을 제시한다. 이는 모든 process가 동시에 점유한 최대 메모리와는 구분해야 한다. 논문은 PHP와 TensorFlow의 상대적으로 큰 시간 비용을 call stack 기반 오탐 억제와 연결하고, ncnn·Redis의 메모리 비용을 객체 메타데이터와 해제 지연으로 설명한다. 평균 추가 비용을 비계측 실행 대비 비용으로 읽으면 안 된다. 논문이 제시한 native 대비 전체 비용은 실행시간 약 1.92배, 메모리 약 2.31배이다(§5.3, §6).

=== 오탐과 알려진 버그 ===
네 가지 오탐 회피를 모두 끄면 12개 중 5개 애플리케이션에서 오탐이 발생했다. gRPC는 1,030개 workload 중 110개(10.68%), MicroPython은 922개 중 298개(32.32%)가 실패했고, Redis·PHP·TensorFlow는 테스트 전에 종료되었다. 기능을 활성화하면 이 평가의 오탐은 모두 제거되었다(Table 3). gRPC·PHP·RocksDB를 대상으로 한 추가 24시간 fuzzing에서도 오탐이 관측되지 않았다(Table 9). 이는 평가한 실행 범위에서의 결과이다.

PHP와 ImageMagick의 알려진 CMA 버그 10건은 Shim을 끈 ASan에서는 검출되지 않았으나, Shim을 끈 CMASan에서는 모두 검출되었다(Table 4). 이 비교는 수동 Shim 없이 CMA를 지원한다는 근거이며, 올바르게 설정된 Shim보다 언제나 우월하다는 비교는 아니다.

=== 신규 버그와 메커니즘의 효과 ===
Table 5의 신규 버그는 7개 프로젝트에서 총 19건으로, BOF 11건과 UAF 8건이다. MicroPython 9건, qhull 2건, RapidJSON 3건, SQLite3 1건, PHP 2건, Taichi 1건, ncnn 1건이며, 평가 조건에서 ASan과 Goshawk는 이들을 검출하지 못했다. Goshawk는 BOF를 지원하지 않으며 UAF 사례에서는 API 식별 실패, clear/realloc 모델링 한계, 복잡한 경로 등의 문제가 있었다.

논문 작성 시점의 Table 5 상태는 '''patched & CVE 6건, patched 1건, confirmed 5건, reported 7건'''이다. 따라서 수정된 버그는 7건이고 그중 6건에 CVE가 있으며, 수정된 건을 포함하여 확인된 것은 12건이다. MicroPython 버그와 PHP 버그 1건은 AFL++ fuzzing으로, 나머지는 unit test로 발견했다.

MicroPython의 CVE-2023-7152와 qhull의 Issue #136-2는 quarantine이 없으면 빠른 객체 재사용 때문에 검출되지 않았다. RapidJSON의 PR #2244와 PR #2256은 clear 이후 UAF로, allocation zone과 clear 처리의 필요성을 보여준다. SQLite3의 CVE-2023-7104와 PHP의 Issue #13230은 기존 테스트에서 각각 9년, 2년 동안 놓친 사례이다(§5.6).

== Contribution ==
# 실제 CMA 사용 사례를 조사하여 Arena의 내부 객체 경계와 Recycler의 독립적인 객체 수명이 ASan의 주요 탐지 공백임을 설명했다.
# CMA를 표준 allocator로 대체하지 않고, API 계측과 별도 메타데이터로 CMA 객체의 공간·시간적 오류를 검사하는 sanitizer를 설계했다.
# Instance별 quarantine, clear용 allocation zone, 네 가지 오탐 회피로 CMA 특유의 수명 관리와 내부 접근을 처리했다.
# 12개 애플리케이션의 추가 비용·오탐 평가와 알려진 버그 10건 및 신규 버그 19건의 검출을 통해 실제 적용 가능성을 보였다.

== Criticisms ==
* '''API 식별의 완전성과 유지 비용''': 이름 휴리스틱, 같은 module의 family 관계, 사람의 의미 분류에 의존한다. 특이한 이름이나 파일을 가로지르는 allocator 구조에서 누락이 없는지, 코드 변경 후 재분류 비용이 얼마나 드는지는 별도 검증이 필요하다. 약 10분이라는 수치는 평가 대상에서의 적용 비용이다.
* '''검사 억제의 범위''': stack에 CMA 함수가 있으면 오류 보고를 억제하므로 CMA 내부 버그는 기본 탐지 범위 밖이다. 연구적 해석으로는 해당 문맥에서 실행되는 callback 등도 검사를 얼마나 잃는지 확인할 필요가 있다. 억제를 끄면 내부 오류를 탐색할 수 있지만 합법적인 메타데이터 접근과의 구분 문제가 다시 생긴다.
* '''유한한 temporal coverage''': quarantine 퇴출 후 주소가 재사용되면 오래된 포인터를 항상 구별할 수 없고, clear 추적도 기본 최근 10,000개 객체로 제한된다. 따라서 모든 UAF/DF 검출을 보장하지 않는다. 기본 한도를 변화시킨 탐지율·메모리·성능의 관계가 더 필요하다.
* '''Allocator 동작에 미치는 영향''': CMA 알고리즘을 교체하지 않아도 요청 크기 증가, free 지연, inlining 금지는 실행을 바꾼다. 실제 RocksDB에서는 할당량 기반 최적화 조건이 바뀌어 일부 unit test가 실패했고 threshold 또는 redzone 조정이 필요했다. PHP에서도 ASan/CMASan의 실행 비용으로 timeout 조정이 필요했다(§6).
* '''평균값과 평가 범위''': 평균 메모리 증가 14.83%와 달리 ncnn은 99.09%이다. 12개 프로젝트는 빌드와 workload 조건으로 선택된 집합이므로 모든 CMA에 비용을 일반화하기 어렵다. 오탐 회피 전체를 끈 비교와 사례별 분석은 있지만, 각 기능의 비용과 false negative 증가를 분리한 정량 평가에는 여지가 있다.
* '''언어·컴파일러 일반성''': C/C++ 중심의 평가이며 typed alloc 처리는 opaque pointer를 끈 LLVM 구성에 의존한다. Appendix E도 ASan의 언어 지원만으로 CMA 식별까지 자동 지원되는 것은 아니며, Rust 등에는 추가 작업이 필요함을 인정한다.

== Conclusion ==
CMASan은 sanitizer의 탐지 공백을 '''CMA가 정의한 객체 경계·수명과 ASan이 관측하는 경계·수명의 불일치'''로 설명한다. CMA API의 의미를 계측과 연결하고 재사용 및 bulk clear를 추적하면, 기존 테스트가 실행하던 오류도 새로 검출할 수 있음을 보였다. CMA 사용자 코드의 메모리 안전성 검사와 allocator-aware sanitizer의 관련 연구로 중요하며, API 분류의 정확도, 검사 억제 범위, 크기·수명 변경의 영향을 함께 고려해야 한다.

[[분류: IEEE S&P]]

Memory Sanitizer

Ahn9807 — Thu, 15 Oct 2026 04:31:52 GMT

Sanitizer 문서로 넘겨주기

새 문서

#넘겨주기 [[Sanitizer]]

Code sanitizer

Ahn9807 — Thu, 15 Oct 2026 04:31:32 GMT

Ahn9807님이 Code sanitizer 문서를 Sanitizer 문서로 이동했습니다

@@ 1번째 줄: / 1번째 줄: @@
-[[분류: 소프트웨어 기반 보안]]
+[[분류:소프트웨어 기반 보안]]
 == 개요 ==
-Code santizier은 [[Compiler]] [[Instrumentation]]을 활용하여서 Runtime에 버그를 잡는 Programming tool을 의미한다. 대표적인 예로 [[Shadow memory]]를 활용하셔어 [[Memory corruption]]을 추적하는 [[AddressSanitizer]]과 같은 툴이 있다.
+Sanitizer는 [[Compiler]] [[Instrumentation]]을 활용하여서 Runtime에 버그를 잡는 Programming tool을 의미한다. 대표적인 예로 [[Shadow memory]]를 활용하셔어 [[Memory corruption]]을 추적하는 [[AddressSanitizer]]과 같은 툴이 있다.
 == 종류 ==
-* Performance와 Memory overhead는 서로 trade-off관계이 있는 경우가 대다수임
+Sanitizer는 Memory Safety를 검사하기 위해 필요한 Metadata를 어떤 방식으로 찾는지에 따라 크게 두 가지로 나눌 수 있다. 이때 Metadata를 찾는 데 사용하는 기준을 '''Identity Unit'''이라고 한다.
-* Scalability는 멀티 스레딩 환경 (보통 [[PARSEC]])에서 어느정도 Scalability를 보였는지를 표시, ? (멀티 스레딩 구현 안함, 측정 안함), Low - Moderate - High로 표기
+효율적인 Identity Unit은 Metadata Lookup이 빠르고, 메모리가 해제되거나 재사용되더라도 Identity가 안정적으로 유지되어야 하며, Object의 Bounds와 Liveness 정보를 식별할 수 있어야 한다. 빠른 Metadata Lookup은 Runtime Overhead를 줄이고, 안정적인 Identity는 Quarantine 없이도 Temporal Bug를 검출할 수 있도록 하며, 정확한 Bounds Metadata는 큰 Redzone 없이도 Spatial Bug를 검출할 수 있도록 한다.
-* Transparency는 Application수정 필요한지 표기. Yes (Full transparent), No (특정 기능이 없거나, 전체적으로 다시 구현해야 하는 경우)
+기존 Sanitizer들은 Identity Unit을 정의하는 방식에 따라 '''Location-based Sanitizer'''와 '''Identity-based Sanitizer'''로 구분할 수 있다.
 === Sanitizer 관련 프로젝트 정리 ===

GPU Memory Architecture

Ahn9807 — Tue, 13 Oct 2026 08:20:38 GMT

← 이전 판		2026년 10월 13일 (화) 08:20 판
1번째 줄:		1번째 줄:
	[[분류: GPU]]		[[분류: GPU Memory Management]]

	== 개요 ==		== 개요 ==

분류:GPU Memory Management

Ahn9807 — Tue, 13 Oct 2026 08:20:01 GMT

새 문서: 분류: GPU

새 문서

[[분류: GPU]]

RAPIDS Memory Allocator

Ahn9807 — Tue, 13 Oct 2026 08:19:51 GMT

← 이전 판		2026년 10월 13일 (화) 08:19 판
(같은 사용자의 중간 판 하나는 보이지 않습니다)
1번째 줄:		1번째 줄:
	[[분류: GPU ~~아키텍쳐~~]]		[[분류: GPU Memory Management]]

	== 개요 ==		== 개요 ==

RAPIDS Memory Allocator

Ahn9807 — Tue, 13 Oct 2026 08:17:48 GMT

새 문서: 분류: GPU 아키텍쳐 == 개요 == RAPIDS Memory Manager(RMM)는 High-frequency memory allocation/deallocation에서 발생하는 병목현상을 줄이고, 다양한 메모리 할당 전략을 제공하는 Memory management library이다. Pooling을 사용하는 경우, 큰 메모리 영역을 확보한 뒤 개별 Allocation 요청에 따라 Suballocation하고 재사용함으로써 <code>cudaMalloc</code>이나 <code>cudaFree</code>의 호출 빈도와 관련 Overhead...

새 문서

[[분류: GPU 아키텍쳐]]

== 개요 ==
RAPIDS Memory Manager(RMM)는 High-frequency memory allocation/deallocation에서 발생하는 병목현상을 줄이고, 다양한 메모리 할당 전략을 제공하는 Memory management library이다. Pooling을 사용하는 경우, 큰 메모리 영역을 확보한 뒤 개별 Allocation 요청에 따라 Suballocation하고 재사용함으로써 <code>cudaMalloc</code>이나 <code>cudaFree</code>의 호출 빈도와 관련 Overhead를 줄인다.

RMM은 공통된 Memory resource interface를 통해서 단순한 CUDA Allocation부터 Pooling, 크기별 Allocation, Logging 등 다양한 방식을 선택하고 조합할 수 있도록 한다.

== 배경 ==
GPU workflow를 최적화하기 위해서는 Host와 Device memory의 할당 방식도 함께 고려해야 한다. 예를 들어서 빈번한 Device memory allocation의 비용을 줄이기 위해 Memory pool을 사용하거나, 비동기 Host-device memory transfer를 위해 Pinned host memory를 사용할 수 있다.

더 나아가서 Memory diagnostics, logging, leak detection, profiling, debugging 등의 기능을 메모리 할당 과정에 적용할 필요가 있다. 이러한 기능을 각각 구현하기보다는 공통된 Memory allocation interface를 통해서 제공하면 메모리 관리를 쉽게 확장할 수 있다.

RMM은 이런 환경에서 Device와 Host memory allocation을 쉽고 효과적으로 Customizing할 수 있는 Interface와 이를 사용하는 자료구조를 제공한다. RMM은 이미 [[NVIDIA]] [[RAPIDS 라이브러리]] 전반에 걸쳐서 사용되고 있다.

== 내부 구조 ==
=== Stream-ordered Memory Allocation ===
RMM은 Stream을 인자로 받는 Allocation과 Deallocation interface를 제공한다. 전통적인 <code>cudaMalloc</code>과 <code>cudaFree</code>는 Stream을 인자로 받지 않으며, 특히 <code>cudaMalloc</code>으로 할당한 메모리를 <code>cudaFree</code>로 해제하는 과정에서는 Device 전체의 Synchronization이 발생할 수 있다.

Stream-ordered allocation은 메모리의 할당, 사용, 해제, 재사용 순서를 Stream의 실행 순서와 연결한다. 같은 Stream에서는 앞선 작업이 끝난 뒤 다음 작업이 실행되므로, 해제된 메모리를 재사용할 때 별도로 Stream 전체가 끝나기를 기다리는 Synchronization을 피할 수 있다. 즉, 매번 해당 Stream을 Synchronize하는 방식이 아니라 Stream ordering을 이용해서 불필요한 동기화를 줄이는 방식이다.

=== Suballocation in RMM ===
RMM은 여러 종류의 Suballocator를 제공한다. Suballocator는 Upstream memory resource에서 큰 메모리 영역을 확보한 뒤, 이를 작은 영역으로 나누어서 개별 Allocation 요청을 처리한다. 따라서 매번 CUDA Allocation을 수행하지 않고도 Pool 내부에서 메모리를 할당하고 재사용할 수 있다.

<code>pool_memory_resource</code>는 Coalescing best-fit 방식의 Suballocator이다. 메모리가 Free되면 주소상 인접한 Free block들과 병합해서 Fragmentation을 줄인다. 또한 Stream마다 Free list를 관리해서 같은 Stream에서 해제된 Block을 동기화 없이 재사용할 수 있도록 한다. 해당 Stream의 Free list에 충분한 크기의 Block이 없으면 다른 Stream의 Free list를 검색할 수 있으며, 이 경우 Event를 통해서 필요한 실행 순서를 보장한다. 따라서 Stream마다 완전히 독립된 Pool이 존재한다기보다는, 재사용 가능한 Block을 Stream별 Free list로 관리한다고 보는 것이 정확하다.

<code>binning_memory_resource</code>는 Allocation 크기에 따라 서로 다른 Memory resource로 요청을 전달한다. 예를 들어서 작은 Allocation은 <code>fixed_size_memory_resource</code>로 처리하고, 큰 Allocation은 Upstream memory resource로 전달하는 Hybrid approach를 구성할 수 있다.

<code>arena_memory_resource</code>는 Global arena와 Default stream을 위한 Per-thread arena, Non-default stream을 위한 Per-stream arena를 사용한다. 각 Local arena는 Global arena에서 Superblock 단위로 메모리를 받아서 관리한다. 작은 Allocation은 Local arena에서 처리하고 큰 Allocation은 Global arena를 활용하는 방식으로, 여러 Thread와 Stream이 함께 사용하는 환경에서 동시성과 Fragmentation을 고려한다.

대문

Ahn9807 — Tue, 13 Oct 2026 05:42:53 GMT

← 이전 판		2026년 10월 13일 (화) 05:42 판
22번째 줄:		22번째 줄:
	✉️ junhoahn@kaist.ac.kr <br>		✉️ junhoahn@kaist.ac.kr <br>
	<div class="home-link__button">[https://sites.google.com/view/junhoahn/ Curriculum Vitae]</div>		<div class="home-link__button">[https://sites.google.com/view/junhoahn/ Curriculum Vitae]</div>
			<div class="home-link__button">[https://tech.junhoahn.kr/ Tech Blog]</div>
	</div>		</div>
	</div>		</div>

Scalable Address Spaces using Concurrent Interval Skiplist

Ahn9807 — Mon, 12 Oct 2026 10:02:18 GMT

@@ 36번째 줄: / 36번째 줄: @@
 == Main Idea ==
-핵심은 주소 구간의 '''검색과 잠금 획득을 한 자료구조의 연속된 동작으로 통합'''하는 것이다. Concurrent interval skiplist는 각 node와 뒤따르는 gap을 잠그면서 필요한 구간을 찾아가므로, map을 먼저 읽고 별도의 range lock을 나중에 잡는 사이의 race를 피한다. 겹치지 않는 구간의 갱신은 병렬로 진행하고, lock-free Query를 위해 여러 node의 교체는 [[Read-copy-update|RCU]] 방식으로 한 번에 commit한다(§4).
+기존의 Address Space는 다음 세개의 Operation만을 제공하였다.
-이를 실제 kernel 주소 공간으로 확장하려면 전역 작업에는 별도의 per-core lock 층을 쓰고, Alloc은 core별 arena로 분산하며, 엄격한 resource limit을 유지하는 counter도 분산해야 한다(§5). 즉 skiplist가 핵심이지만, 성능 개선은 이 주변 메커니즘을 함께 적용한 결과다.
+== Design ==
-== Design ==
+; Two-level Locking for Hybrid Granularity
-# '''Concurrent interval skiplist (§4):''' 기존 interval map의 Query·Map·Alloc에 Lock·Unlock·Swap을 더한다. Lock은 predecessor부터 대상 node와 gap을 순차적으로 잠근다. level-0 link의 <code>LOCKED</code> 표시가 node와 뒤따르는 gap을 보호하므로, 인접한 VMA나 빈 구간을 함께 다뤄야 하는 Modify에도 적용된다. Skip link는 탐색을 빠르게 하되 잠금은 level 0에서만 수행한다.
+: 전체 Address space를 보호하는 Global read/write(GR/GW)와 특정 interval을 보호하는 Local read/write(LR/LW)를 제공한다. 이를 위해 per-core read-write lock을 두고, Global operation은 모든 core의 lock을 획득하며 Local operation은 현재 core의 lock과 필요한 skiplist interval lock을 획득한다. 이를 통해서 fork, exit과 같은 operation에서 모든 VMA의 lock을 개별적으로 획득하는 오버헤드를 줄이면서, 서로 다른 interval의 operation은 병렬로 실행할 수 있다.
-# '''원자적 다중 node 갱신과 Query (§4):''' Map/Swap은 새 node들을 준비한 후 predecessor link를 CAS로 바꾸어 교체를 commit하고, 옛 node를 <code>INVALIDATED</code>로 표시한다. Query는 잠금 없이 전·후 상태 중 하나를 읽도록 설계한다. 높은 skiplist level의 link는 교체 전후에 묶어서 정리·삽입한다. 이 방식은 구간 전체를 잠그지 않고도 여러 VMA에 걸친 갱신을 처리하지만, tree보다 Query의 cache locality가 나쁠 수 있다.
-# '''전역/국소 2단계 잠금 (§5.1):''' global read/write(GR/GW)는 모든 per-core RW lock을 잡고, local read/write(LR/LW)는 실행 core의 lock과 해당 skiplist interval lock을 잡는다. 따라서 <code>fork()</code>·<code>exit()</code> 같은 전역 작업에서 모든 VMA lock을 열거할 필요가 없고, 겹치지 않는 국소 작업은 병렬 실행된다. 지원하지 않는 일부 경로는 전역 lock으로 fallback한다.
+; Page Fault
-# '''Fault·Alloc·Modify 경로 (§5.2–5.4):''' Fault는 가능한 경우 주소 공간 lock 없이 시도하고, page table 생성·VMA 초기화 등 동기화가 필요하면 LR, 예외적 file-backed 경로에서는 GR로 진행한다. Alloc은 새 VMA를 삽입 전에 준비하고 CAS 삽입으로 commit한다. <code>munmap()</code>·<code>mprotect()</code> 등의 Modify는 동적으로 확인한 구간을 LW로 잠그며, 미적응 경로에서는 GW를 사용한다.
+: 먼저 Address space lock 없이 page fault를 처리하도록 시도한다. 이때 다른 interval의 update로 인한 불필요한 abort를 줄인다. 새로운 page table의 할당이나 VMA 초기화, file system과의 동기화가 필요하면 LR mode와 interval lock을 획득하여 처리한다. 이 방식으로 처리할 수 없는 일부 file-backed memory 경로에서는 GR mode로 fallback한다.
-# '''분산 Alloc과 제한 계수 (§5.3):''' 각 core는 우선 자기 64 GiB arena에서 빈 공간을 찾는다. Separator node와 계층화한 skiplist level이 arena 간 skip-link 간섭을 줄이고, arena hint는 해제된 공간의 재사용을 돕는다. Resource counter는 per-core batch를 사용하다가 limit에 가까워지면 global counter 직접 갱신으로 전환하여 strict limit을 지킨다. 구현에서 최대 128개 arena는 256 TiB 주소 공간의 4% 미만을 차지한다.
 == Result ==
@@ 60번째 줄: / 99번째 줄: @@
 |}
-== Contribution ==
+[[분류:ACM SOSP]]

파일:SOSP 2025 Skiplist Figure 8.png

Ahn9807 — Mon, 12 Oct 2026 07:11:53 GMT

Ahn9807님이 파일:SOSP 2025 Skiplist Figure 8.png 파일을 올렸습니다

새 문서

SOSP 2025 Skiplist Figure 8

Scalable Address Spaces using Concurrent Interval Skiplist

Ahn9807 — Mon, 12 Oct 2026 06:31:14 GMT

@@ 10번째 줄: / 10번째 줄: @@
 == Motivation ==
-Linux 6.8.0은 per-VMA locking으로 많은 page fault를 갱신과 병렬 실행할 수 있지만, 주소 공간을 할당하는 Alloc과 기존 mapping을 바꾸는 Modify는 여전히 <code>mmap_lock</code>을 write mode로 잡는다. 다중 arena를 사용하는 [[Memory allocator]]와 file-backed mapping을 많이 여닫는 응용에서는 이 직렬화가 커진다. 논문의 lockstat 측정에서 높은 thread 수의 <code>mmap_lock</code> 대기 시간 비율은 Apache 최대 90%, Metis 60%, Psearchy 41%, LevelDB 40%에 이른다(Fig. 1).
+Linux 6.8.0은 per-VMA locking으로 많은 page fault를 갱신과 병렬 실행할 수 있지만, 주소 공간을 할당하는 Alloc과 기존 mapping을 바꾸는 Modify는 여전히 <code>mmap_lock</code>을 write mode로 잡는다. 다중 arena를 사용하는 [[Memory allocator]]와 file-backed mapping을 많이 여닫는 응용에서는 이 직렬화가 커진다. 논문의 lockstat 측정에서 높은 thread 수의 <code>mmap_lock</code> 대기 시간 비율은 Apache 최대 90%, Metis 60%, Psearchy 41%, LevelDB 40%에 이른다고 한다.
-단순한 range lock 교체도 어렵다. 작업 대상 구간과 VMA 또는 page table의 경계가 일치하지 않아 실제 잠글 범위가 현재 mapping 상태에 따라 바뀐다. 예를 들어 <code>munmap()</code>은 빈 page table을 안전하게 해제하려면 이웃한 gap까지 보호해야 한다(Fig. 3–4). 먼저 map을 탐색하고 나중에 range를 잠그면 그 사이의 갱신으로 탐색 결과가 낡을 수 있다.
+== Challenges ==
 == Main Idea ==
@@ 50번째 줄: / 71번째 줄: @@
-[[분류: ACM SOSP]]
+[[index.php?title=분류:ACM SOSP]]

Scalable Address Spaces using Concurrent Interval Skiplist

Noribot — Sat, 03 Oct 2026 06:35:20 GMT

Nori: update draft.wikitext

새 문서

{{Paper
|title=Scalable Address Spaces using Concurrent Interval Skiplist
|author=Tae Woo Kim, Youngjin Kwon, Jeehoon Kang
|conference=ACM SIGOPS Symposium on Operating Systems Principles (SOSP)
|year=2025
}}

== 개요 ==
이 논문은 멀티스레드 프로세스의 [[Virtual memory|가상 주소 공간]]에서 <code>mmap()</code>·<code>munmap()</code> 등 갱신 작업이 <code>mmap_lock</code>에 의해 직렬화되는 문제를, mapping과 interval locking을 결합한 concurrent interval skiplist 및 주소 공간 설계로 해결하였다.

== Motivation ==
Linux 6.8.0은 per-VMA locking으로 많은 page fault를 갱신과 병렬 실행할 수 있지만, 주소 공간을 할당하는 Alloc과 기존 mapping을 바꾸는 Modify는 여전히 <code>mmap_lock</code>을 write mode로 잡는다. 다중 arena를 사용하는 [[Memory allocator]]와 file-backed mapping을 많이 여닫는 응용에서는 이 직렬화가 커진다. 논문의 lockstat 측정에서 높은 thread 수의 <code>mmap_lock</code> 대기 시간 비율은 Apache 최대 90%, Metis 60%, Psearchy 41%, LevelDB 40%에 이른다(Fig. 1).

단순한 range lock 교체도 어렵다. 작업 대상 구간과 VMA 또는 page table의 경계가 일치하지 않아 실제 잠글 범위가 현재 mapping 상태에 따라 바뀐다. 예를 들어 <code>munmap()</code>은 빈 page table을 안전하게 해제하려면 이웃한 gap까지 보호해야 한다(Fig. 3–4). 먼저 map을 탐색하고 나중에 range를 잠그면 그 사이의 갱신으로 탐색 결과가 낡을 수 있다.

== Main Idea ==
핵심은 주소 구간의 '''검색과 잠금 획득을 한 자료구조의 연속된 동작으로 통합'''하는 것이다. Concurrent interval skiplist는 각 node와 뒤따르는 gap을 잠그면서 필요한 구간을 찾아가므로, map을 먼저 읽고 별도의 range lock을 나중에 잡는 사이의 race를 피한다. 겹치지 않는 구간의 갱신은 병렬로 진행하고, lock-free Query를 위해 여러 node의 교체는 [[Read-copy-update|RCU]] 방식으로 한 번에 commit한다(§4).

이를 실제 kernel 주소 공간으로 확장하려면 전역 작업에는 별도의 per-core lock 층을 쓰고, Alloc은 core별 arena로 분산하며, 엄격한 resource limit을 유지하는 counter도 분산해야 한다(§5). 즉 skiplist가 핵심이지만, 성능 개선은 이 주변 메커니즘을 함께 적용한 결과다.

== Design ==
# '''Concurrent interval skiplist (§4):''' 기존 interval map의 Query·Map·Alloc에 Lock·Unlock·Swap을 더한다. Lock은 predecessor부터 대상 node와 gap을 순차적으로 잠근다. level-0 link의 <code>LOCKED</code> 표시가 node와 뒤따르는 gap을 보호하므로, 인접한 VMA나 빈 구간을 함께 다뤄야 하는 Modify에도 적용된다. Skip link는 탐색을 빠르게 하되 잠금은 level 0에서만 수행한다.
# '''원자적 다중 node 갱신과 Query (§4):''' Map/Swap은 새 node들을 준비한 후 predecessor link를 CAS로 바꾸어 교체를 commit하고, 옛 node를 <code>INVALIDATED</code>로 표시한다. Query는 잠금 없이 전·후 상태 중 하나를 읽도록 설계한다. 높은 skiplist level의 link는 교체 전후에 묶어서 정리·삽입한다. 이 방식은 구간 전체를 잠그지 않고도 여러 VMA에 걸친 갱신을 처리하지만, tree보다 Query의 cache locality가 나쁠 수 있다.
# '''전역/국소 2단계 잠금 (§5.1):''' global read/write(GR/GW)는 모든 per-core RW lock을 잡고, local read/write(LR/LW)는 실행 core의 lock과 해당 skiplist interval lock을 잡는다. 따라서 <code>fork()</code>·<code>exit()</code> 같은 전역 작업에서 모든 VMA lock을 열거할 필요가 없고, 겹치지 않는 국소 작업은 병렬 실행된다. 지원하지 않는 일부 경로는 전역 lock으로 fallback한다.
# '''Fault·Alloc·Modify 경로 (§5.2–5.4):''' Fault는 가능한 경우 주소 공간 lock 없이 시도하고, page table 생성·VMA 초기화 등 동기화가 필요하면 LR, 예외적 file-backed 경로에서는 GR로 진행한다. Alloc은 새 VMA를 삽입 전에 준비하고 CAS 삽입으로 commit한다. <code>munmap()</code>·<code>mprotect()</code> 등의 Modify는 동적으로 확인한 구간을 LW로 잠그며, 미적응 경로에서는 GW를 사용한다.
# '''분산 Alloc과 제한 계수 (§5.3):''' 각 core는 우선 자기 64 GiB arena에서 빈 공간을 찾는다. Separator node와 계층화한 skiplist level이 arena 간 skip-link 간섭을 줄이고, arena hint는 해제된 공간의 재사용을 돕는다. Resource counter는 per-core batch를 사용하다가 limit에 가까워지면 global counter 직접 갱신으로 전환하여 strict limit을 지킨다. 구현에서 최대 128개 arena는 256 TiB 주소 공간의 4% 미만을 차지한다.

== Result ==
{| class="wikitable"
! 실험 !! Linux 6.8.0 대비 IntervalVM !! 의미
|-
| <code>mmap()</code> Alloc microbenchmark || peak throughput 13.1× || Alloc 병렬화의 효과. Arena 또는 per-core statistics를 끄면 확장성이 크게 떨어져 여러 병목을 함께 해결해야 함(Fig. 14).
|-
| Alloc + Fault + Modify microbenchmark || peak throughput 10.4× || 실제 mapping 수명 주기에 가까운 반복 작업에서도 효과가 유지됨(Fig. 14).
|-
| Apache || 단일 프로세스 4.53×; 기본 다중 프로세스 설정 3.19× || Fault·Alloc·Modify 중 하나의 병렬화를 끄면 처리량이 감소함(Fig. 15–16).
|-
| LevelDB / Metis / Psearchy || 각각 4.49× / 1.47× / 1.27× || workload가 VM 작업을 많이 할수록 <code>mmap_lock</code> 제거의 이득이 나타남(Fig. 15).
|}

== Contribution ==
# 실제 kernel 주소 공간의 병렬화를 막는 다섯 병목을 분해하고, 동적 잠금 구간이 mapping 상태에 의존한다는 점을 명확히 했다.
# 잠금과 interval map을 결합한 concurrent interval skiplist로 겹치지 않는 구간의 갱신 및 RCU-safe lock-free 조회를 함께 지원했다.
# 전역/국소 잠금, per-core arena, adaptive counter를 결합해 POSIX 응용 수정 없이 Linux에서 Fault·Alloc·Modify의 주요 경로를 병렬화했다.
# Microbenchmark, 서버·DB·MapReduce·색인 workload 및 PARSEC로 이득과 단일 연산 비용을 함께 측정했다.

== Criticisms ==

== [[Conclusion]] ==

[[분류: ACM SOSP]]