Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

윈도우 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 주소가 한 개 사용된 것을 볼 수 있었습니다. ^^

old_story_x64_1.png




그런데, 여기서 또 재미있는 점은 위의 메모장에도 나오지만 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에서 하게 된 것이고, 이후 우리가 볼 수 있었던 현상들의 원인이 된 것입니다.





[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 12/6/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  5  6  7  8  9  10  [11]  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13308정성태4/4/20233119스크립트: 47. 파이썬의 time.time() 실숫값을 GoLang / C#에서 사용하는 방법
13307정성태4/4/20232928.NET Framework: 2106. C# - .NET Core/5+ 환경의 Windows Forms 응용 프로그램에서 HINSTANCE 구하는 방법
13306정성태4/3/20232815Windows: 243. Win32 - 윈도우(cbWndExtra) 및 윈도우 클래스(cbClsExtra) 저장소 사용 방법
13305정성태4/1/20233071Windows: 242. Win32 - 시간 만료를 갖는 MessageBox 대화창 구현 (쉬운 버전)파일 다운로드1
13304정성태3/31/20233392VS.NET IDE: 181. Visual Studio - C/C++ 프로젝트에 application manifest 적용하는 방법
13303정성태3/30/20232721Windows: 241. 환경 변수 %PATH%에 DLL을 찾는 규칙
13302정성태3/30/20233319Windows: 240. RDP 환경에서 바뀌는 %TEMP% 디렉터리 경로
13301정성태3/29/20233423Windows: 239. C/C++ - Windows 10 Version 1607부터 지원하는 /DEPENDENTLOADFLAG 옵션파일 다운로드1
13300정성태3/28/20233135Windows: 238. Win32 - Modal UI 창에 올바른 Owner(HWND)를 설정해야 하는 이유
13299정성태3/27/20232904Windows: 237. Win32 - 모든 메시지 루프를 탈출하는 WM_QUIT 메시지
13298정성태3/27/20232820Windows: 236. Win32 - MessageBeep 소리가 안 들린다면?
13297정성태3/26/20233447Windows: 235. Win32 - Code Modal과 UI Modal
13296정성태3/25/20232865Windows: 234. IsDialogMessage와 협업하는 WM_GETDLGCODE Win32 메시지 [1]파일 다운로드1
13295정성태3/24/20233064Windows: 233. Win32 - modeless 대화창을 modal처럼 동작하게 만드는 방법파일 다운로드1
13294정성태3/22/20233309.NET Framework: 2105. LargeAddressAware 옵션이 적용된 닷넷 32비트 프로세스의 가용 메모리 - 두 번째
13293정성태3/22/20233397오류 유형: 853. dumpbin - warning LNK4048: Invalid format file; ignored
13292정성태3/21/20233324Windows: 232. C/C++ - 일반 창에도 사용 가능한 IsDialogMessage파일 다운로드1
13291정성태3/20/20233805.NET Framework: 2104. C# Windows Forms - WndProc 재정의와 IMessageFilter 사용 시의 차이점
13290정성태3/19/20233341.NET Framework: 2103. C# - 윈도우에서 기본 제공하는 FindText 대화창 사용법파일 다운로드1
13289정성태3/18/20232627Windows: 231. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 자식 윈도우를 생성하는 방법파일 다운로드1
13288정성태3/17/20232743Windows: 230. Win32 - 대화창의 DLU 단위를 pixel로 변경하는 방법파일 다운로드1
13287정성태3/16/20232910Windows: 229. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 윈도우를 직접 띄우는 방법파일 다운로드1
13286정성태3/15/20233368Windows: 228. Win32 - 리소스에 포함된 대화창 Template의 2진 코드 해석 방법
13285정성태3/14/20232927Windows: 227. Win32 C/C++ - Dialog Procedure를 재정의하는 방법파일 다운로드1
13284정성태3/13/20233098Windows: 226. Win32 C/C++ - Dialog에서 값을 반환하는 방법파일 다운로드1
13283정성태3/12/20232662오류 유형: 852. 파이썬 - TypeError: coercing to Unicode: need string or buffer, NoneType found
1  2  3  4  5  6  7  8  9  10  [11]  12  13  14  15  ...