윈도우 x64의 경우 0x00000000`7ffe0000 아래의 주소는 왜 사용하지 않을까요?
요즘 옛날 이야기가 재미있어지는군요. ^^ Raymond Chen의 재미있는 글을 또 하나 들고 왔습니다.
Why doesn’t Windows use the 64-bit virtual address space below 0x00000000`7ffe0000?
; https://devblogs.microsoft.com/oldnewthing/20221216-00/?p=107598
사실, 저는 그동안 64비트 응용 프로그램은 4GB 주소 위에서만 할당이 된다고 어렴풋이 가정했었습니다. 왜냐하면 그동안 제가 windbg로 분석할 때마다 모듈의 주소가 하나같이 매우 컸기 때문입니다.
// 메모장을 실행한 후 Windbg로 확인한 모듈의 로딩 주소
ModLoad: 00007ff7`87300000 00007ff7`87384000 C:\Program Files\WindowsApps\Microsoft.WindowsNotepad_11.2210.5.0_x64__8wekyb3d8bbwe\Notepad\Notepad.exe
ModLoad: 00007ffb`6ff50000 00007ffb`70164000 C:\WINDOWS\SYSTEM32\ntdll.dll
ModLoad: 00007ffb`6f220000 00007ffb`6f2e3000 C:\WINDOWS\System32\KERNEL32.DLL
ModLoad: 00007ffb`6d370000 00007ffb`6d70d000 C:\WINDOWS\System32\KERNELBASE.dll
...[생략]...
ModLoad: 00007ffb`42920000 00007ffb`4293a000 C:\WINDOWS\system32\NetworkExplorer.dll
ModLoad: 00007ffb`393c0000 00007ffb`39489000 C:\Windows\System32\twinapi.dll
ModLoad: 00007ffb`428f0000 00007ffb`42918000 C:\WINDOWS\SYSTEM32\edputil.dll
그래서 아마도 4GB 포인터 주소 연산을 미연에 방지하기 위해 그런가보다... 하고 생각한 건데요, 하지만 질문자는 7ffe0000 아래의 주소를 사용하지 않는 것 같다면서 그 이유를 묻는 것입니다. 재미있는 것은, 32비트 운영체제의 (커널이 아닌) 사용자 주소 영역이 0x0 ~ 0x7FFFFFFF, 즉 0 ~ 2GB인데요, 그 마지막 주소의 언저리에 있는 7ffe0000 주소를 언급했다는 점입니다. 64비트에서
가상 메모리의 할당은 64KB마다 정렬이 된다는 점을 고려했을 때 7ffe0000 주소는 마지막 주소에서 128KB, 정확히 2개의 정렬 단위만큼 떨어진 공간입니다.
이 질문에 대한 Raymond Chen의 대답은 그렇지 않다는 것입니다. 그렇게 나온 주요 원인은, 64비트의 주소 공간이 워낙 크기 떄문이라고 합니다. 원래 64비트로 지정 가능한 주소 공간은 총
16 Exabyte입니다. 하지만, 실제로 거의 대부분 존재하지도 않을 물리 메모리 주소의 공간을 위해 페이징 데이터를 마련해 두면 쓸데 없는 메모리 낭비가 심하기 때문에 일단 그중에서 현실성 있게 256TB까지 윈도우는 지원하고 있으며, 절반을 나눈 하위 128TB는 사용자 영역, 상위 128TB는 커널 영역으로 두었습니다.
그럼, 사용자 영역만 하더라도 128TB인데, 64KB 정렬이라고 가정해 47비트의 값이 ASLR에 의해 무작위로 선택되는 것이므로 그 많은 메모리 주소 공간에서 체 0.003%도 안 되는 2GB 하위의 주소가
ASLR에 의해 선택될 확률이 극히 낮다는 것입니다.
실제로 이걸 증명이라도 하듯 ^^ 하필 제가
VMMap으로 notepad.exe를 연결해 아래와 같이 0x21f60000 주소가 한 개 사용된 것을 볼 수 있었습니다. ^^
그런데, 여기서 또 재미있는 점은 위의 메모장에도 나오지만 0x7ffe0000 주소 공간이 언제나 사용되는 것을 볼 수 있습니다. VMMap으로 현재 실행 중인 어떤 프로세스를 선택해도 하나같이 저 공간이 "Read" 권한으로 사용되고 있는데요, 이에 대해 Raymond Chen은 또 다시 자세한 설명을 하고 있습니다. ^^
그 공간은 커널 모드의 데이터에 대해 속도상의 이유로 사용자 모드에서 커널로의 실행 전환 없이 바로 읽어갈 수 있도록 특별하게 제공되는 단 1개의 읽기 전용 페이지가 있기 때문입니다. 그런데 왜? 64비트 메모리 주소 공간에서 하필 2GB의 바로 하위 가상 주소 공간을 선택한 것일까요? 왜냐하면, 일부 64비트 응용 프로그램들조차도
/LARGEADDRESSAWARE 옵션이 적용되지 않고 빌드된 경우가 있기 때문입니다. 그런 프로그램들은 사용자 메모리 공간으로 2GB만 접근할 수 있으므로 어쩔 수 없이 2GB 바로 하위에 읽기 전용 공간을 매핑한 것입니다.
비록 1개의 페이지만 필요하지만, 가상 주소 공간의 정렬 단위가 64KB이기 때문에 실제로는 0x7ffe0000~0x7ffeffff 공간 전체가 예약됩니다. 아울러, 이 공간에는 Hypervisor를 위해 특별히 커널 모드에서 매핑되는 또 하나의 페이지가 있다고 합니다. ("
Partition Reference Time Stamp Counter Page") 64KB 내에서 (실제로는 이전에 설명한 읽기 전용 페이지로 할당한 4KB를 뺀 60KB) "partition reference time stamp counter"가 위치하는 페이지는 랜덤이지만 이것은 ASLR의 보안상 이유와는 크게 상관이 없다고 합니다. 실제로 60KB / 4KB = 15개에 불과한 페이지 선택 공간에서 임의성을 부여해봤자라서, 그보다는 단순히 고정 주소로 누군가 사용하는 것을 방지하기 위해서라고 합니다. (HV_X64_MSR_REFERENCE_TSC msr에 해당 주소를 담고 있습니다.)
그런데, 왜? 128KB가 떨어진 0x7ffe0000~0x7ffeffff 위치를 공유로 잡았을까요? 마지막인 0x7fff0000~0x7fffffff 위치도 가능했을 텐데...? 한 가지 이유는 주소에 대한
유효성 체크를 쉽게 하도록 일부러 마지막 2GB를 전/후로 한 64KB는 접근 불가능 영역으로 지정했다고 합니다. (null 체크를 위한 메모리 주소 0 위치를 접근 불가능하게 만든 것과 유사하다고 보면 되겠습니다.)
그렇다면, 커널 메모리 주소가 2GB를 기점으로 나뉘지 않는 64비트 시대에도 왜? 그 영역을 접근 불가능 영역으로 놔둔 걸까요?
이것은 Alpha AXP CPU의 특이한 주소 지정 방식 때문이었습니다. 해당 CPU에서는 대부분의 32비트 숫자값을 2번의 연산으로 생성할 수 있었는데요, 유독 "0x7fff8000 to 0x7fffffff" 위치에 한해 3번의 연산을 필요로 했습니다. 성능상 그 부분을 아예 접근 불가능으로 만들어버린 것입니다.
그나저나 꼬리에 꼬리를 물게 되는 질문이 계속해서 나옵니다. 도대체 왜 윈도우가 Intel CPU도 아닌, 뜬금 없이 Alpha AXP로 인한 제약을 받게 된 걸까요? 이에 대한 이야기가 다음의 글에 나옵니다.
Windows ConfidentialBuilding on the Past
; https://learn.microsoft.com/en-us/previous-versions/technet-magazine/cc718978(v=msdn.10)
Filling in some gaps in the story of Space Cadet Pinball on 64-bit Windows
; https://devblogs.microsoft.com/oldnewthing/20220106-00/?p=106122
처음 64비트를 위한 윈도우 프로젝트(
Codename: Sundown)가 시작되었을 당시에는, 인텔에서 물리적으로 구현된 Itanium CPU 하드웨어가 없었다고 합니다. 관련 코드를 돌려볼 수 있는 유일한 방법이 simulator를 사용하는 것인데, 운영체제 규모의 거대한 코드 덩어리를 시뮬레이터에서 돌리면서 개발한다는 것은 극악의 효율이었을 것입니다.
다행히 그당시 64비트 CPU로 Alpha AXP는 충분히 가용했다고 합니다. 왜냐하면, 기존 Windows NT 버전은 Intel, PowerPC, Alpha CPU를 지원하고 있었는데 1999년에 Compaq이 Alpha AXP에서의 윈도우 지원을 종료한다는 발표로 인해,
- 기존의 Alpha AXP 기기들이 갑자기 쓸모 없어졌고
- 반면 적지 않은 개발자들이 Alpah AXP 환경에 경험이 있었고,
- 게다가 32비트 윈도우 NT는 (64비트 CPU인) Alpha AXP를 이미 지원하던 상태였으므로,
자연스럽게 일정과 Itanium 하드웨어의 부재로 인한 문제는 Alpha AXP CPU로 64비트 윈도우를 개발하는 시도로 우회하게 되었다고 합니다. 사실, 32비트 운영체제를 64비트로 처음 한 번 포팅하는 작업이 힘들 뿐, 일단 하나의 성공한 64비트 버전이 있으면 다른 64비트로의 포팅은 이전 작업만큼의 시간을 소요하지는 않을 것이기 때문에 시뮬레이터를 이용한 개발보다는 훨씬 더 효율적인 결정이었을 것입니다.
결국 64비트로의 윈도우 개발은 실제 지원 버전에 포함되지도 않을 Alpha AXP에서 하게 된 것이고, 이후 우리가 볼 수 있었던
현상들의 원인이 된 것입니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]