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)
13244정성태2/5/20233974VS.NET IDE: 179. Visual Studio - External Tools에 Shell 내장 명령어 등록
13243정성태2/5/20234837디버깅 기술: 190. windbg - Win32 API 호출 시점에 BP 거는 방법 [1]
13242정성태2/4/20234278디버깅 기술: 189. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.UnauthorizedAccessException
13241정성태2/3/20233813디버깅 기술: 188. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.IO.FileNotFoundException
13240정성태2/1/20233980디버깅 기술: 187. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.Web.HttpException
13239정성태2/1/20233623디버깅 기술: 186. C# - CacheDependency의 숨겨진 예외 - System.Web.HttpException
13238정성태1/31/20235615.NET Framework: 2092. IIS 웹 사이트를 TLS 1.2 또는 TLS 1.3 프로토콜로만 운영하는 방법
13237정성태1/30/20235280.NET Framework: 2091. C# - 웹 사이트가 어떤 버전의 TLS/SSL을 지원하는지 확인하는 방법
13236정성태1/29/20234950개발 환경 구성: 663. openssl을 이용해 인트라넷 IIS 사이트의 SSL 인증서 생성
13235정성태1/29/20234479개발 환경 구성: 662. openssl - 윈도우 환경의 명령행에서 SAN 적용하는 방법
13234정성태1/28/20235515개발 환경 구성: 661. dnSpy를 이용해 소스 코드가 없는 .NET 어셈블리의 코드를 변경하는 방법 [1]
13233정성태1/28/20236868오류 유형: 840. C# - WebClient로 https 호출 시 "The request was aborted: Could not create SSL/TLS secure channel" 예외 발생
13232정성태1/27/20234690스크립트: 43. uwsgi의 --processes와 --threads 옵션
13231정성태1/27/20233603오류 유형: 839. python - TypeError: '...' object is not callable
13230정성태1/26/20234018개발 환경 구성: 660. WSL 2 내부로부터 호스트 측의 네트워크로 UDP 데이터가 1개의 패킷으로만 제한되는 문제
13229정성태1/25/20234959.NET Framework: 2090. C# - UDP Datagram의 최대 크기
13228정성태1/24/20235075.NET Framework: 2089. C# - WMI 논리 디스크가 속한 물리 디스크의 정보를 얻는 방법 [2]파일 다운로드1
13227정성태1/23/20234794개발 환경 구성: 659. Windows - IP MTU 값을 바꿀 수 있을까요? [1]
13226정성태1/23/20234465.NET Framework: 2088. .NET 5부터 지원하는 GetRawSocketOption 사용 시 주의할 점
13225정성태1/21/20233738개발 환경 구성: 658. Windows에서 실행 중인 소켓 서버를 다른 PC 또는 WSL에서 접속할 수 없는 경우
13224정성태1/21/20234066Windows: 221. Windows - Private/Public/Domain이 아닌 네트워크 어댑터 단위로 방화벽을 on/off하는 방법
13223정성태1/20/20234263오류 유형: 838. RDP 연결 오류 - The two computers couldn't connect in the amount of time allotted
13222정성태1/20/20233926개발 환경 구성: 657. WSL - DockerDesktop.vhdx 파일 위치를 옮기는 방법
13221정성태1/19/20234137Linux: 57. C# - 리눅스 프로세스 메모리 정보파일 다운로드1
13220정성태1/19/20234280오류 유형: 837. NETSDK1045 The current .NET SDK does not support targeting .NET ...
13219정성태1/18/20233853Windows: 220. 네트워크의 인터넷 접속 가능 여부에 대한 판단 기준
1  2  3  4  5  6  7  8  9  10  11  12  13  14  [15]  ...