Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 

(시리즈 글이 8개 있습니다.)
디버깅 기술: 194. Windbg - x64 가상 주소를 물리 주소로 변환
; https://www.sysnet.pe.kr/2/0/13500

디버깅 기술: 203. Windbg - x64 가상 주소를 물리 주소로 변환 (페이지 크기가 2MB인 경우)
; https://www.sysnet.pe.kr/2/0/13836

디버깅 기술: 206. Windbg로 알아보는 PFN (_MMPFN)
; https://www.sysnet.pe.kr/2/0/13844

디버깅 기술: 207. Windbg로 알아보는 PTE (_MMPTE)
; https://www.sysnet.pe.kr/2/0/13845

디버깅 기술: 208. Windbg로 알아보는 Trans/Soft PTE와 2가지 Page Fault 유형
; https://www.sysnet.pe.kr/2/0/13846

디버깅 기술: 209. Windbg로 알아보는 Prototype PTE
; https://www.sysnet.pe.kr/2/0/13848

디버깅 기술: 210. Windbg - 논리(가상) 주소를 Segmentation을 거쳐 선형 주소로 변경
; https://www.sysnet.pe.kr/2/0/13849

디버깅 기술: 212. Windbg - (Ring 3 사용자 모드의) FS, GS Segment 레지스터
; https://www.sysnet.pe.kr/2/0/13852




Windbg - x64 가상 주소를 물리 주소로 변환 (페이지 크기가 2MB인 경우)

지난 글에서,

Windbg - x64 가상 주소를 물리 주소로 변환
; https://www.sysnet.pe.kr/2/0/13500

설명한 내용은 페이지 크기가 4KB인 경우였습니다. 반면, 페이지 크기가 2MB로 할당된 경우도 있을 텐데요,

C# - Windows 운영체제의 2MB Large 페이지 크기 할당 방법
; https://www.sysnet.pe.kr/2/0/13208

이번에는 저렇게 된 경우에 대한 실습을 해보겠습니다. ^^




자, 그럼 실습을 위해 2MB 페이지 크기로 할당된 메모리를 찾아야 하는데요, 다행히 _EPROCESS 구조체가 대개의 경우 2MB 페이지 크기로 할당된 곳에 위치하고 있는 듯합니다.

// Windows 10 x64 (10.0.19045)에서 Local Kernel Debug로 실행 + notepad.exe 하나 띄워 놓고!

lkd>  !process 0 0 notepad.exe
PROCESS ffffd282e4819080
    SessionId: 2  Cid: 277c    Peb: f9fec99000  ParentCid: 1438
    DirBase: 15c4ff000  ObjectTable: ffffe0042587a040  HandleCount: 261.
    Image: notepad.exe

lkd> !pte ffffd282e4819080
                                           VA ffffd282e4819080
PXE at FFFFFEFF7FBFDD28    PPE at FFFFFEFF7FBA5058    PDE at FFFFFEFF74A0B920    PTE at FFFFFEE9417240C8
contains 0A00000207E43863  contains 0A00000207E44863  contains 8A000001302009E3  contains 0000000000000000
pfn 207e43    ---DA--KWEV  pfn 207e44    ---DA--KWEV  pfn 130200    -GLDA--KW-V  LARGE PAGE pfn 130219    

위의 결과를 보면, _EPROCESS 구조체가 담긴 ffffd282e4819080 주소가 PDE 수준에서 pfn 130200을 담고 있으며 "LARGE PAGE"라는 의미에 맞게 "-GLDA--KW-V"에 "L" 비트가 켜져 있습니다. 즉, 2MB 페이지 크기로 할당된 메모리에 위치해 있는 것입니다.

이런 경우에는, 기존의 4KB 페이지 크기에서 offset 값을 9-9-9-9-12로 분해해 계산했던 것을, 대신 마지막 PTE의 offset 값인 9bit도 뒤의 12비트와 결합해 2MB 영역 내에서의 offset 값으로 계산을 해야 합니다.

ulong addr = 0xffffd282e4819080;

ulong mask = 0b_0000_0000_0000_0000_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111;

ulong result = addr & mask;
Console.WriteLine($"Virtual Address: {result:x}");

mask = 0b_1_1111_1111_1111_1111_1111; // 21 bits
result = addr & mask;
Console.WriteLine($"Offset at page: {result:x3}");

addr = addr >> 21;
mask = 0b_1_1111_1111; // 9 bits
result = addr & mask;
Console.WriteLine($"Page Table Selector: {result:x3}");

addr = addr >> 9;
mask = 0b_1_1111_1111; // 9 bits
result = addr & mask;
Console.WriteLine($"Page Directory Pointer Selector: {result:x3}");

addr = addr >> 9;
mask = 0b_1_1111_1111; // 9 bits
result = addr & mask;
Console.WriteLine($"Page Map Level 4 Selector: {result:x3}");

/* 출력 결과:
Virtual Address: d282e4819080
Offset at page: 19080
Page Table Selector: 124
Page Directory Pointer Selector: 00b
Page Map Level 4 Selector: 1a5
*/

정말 그런지 DirBase로부터 물리 주소를 계산해 볼까요? ^^

"!process ..." 문맥의 결과로 나온 (CR3 레지스터의 값인) 15c4ff000을 기준으로 PML4E 값을 덤프하고,

lkd> ? 1a5*8 // 1개의 항목 크기가 8바이트이므로!
Evaluate expression: 3368 = 00000000`00000d28

lkd> dq /p 15c4ff000+d28 L1 // 또는 !dq 15c4ff000+d28 L1
00000001`5c4ffd28  0a000002`07e43863

// PML4E의 12 ~ 51 영역이 가리키는 Page Directory Pointer == 207e43000

그럼 다시 8바이트 크기의 Page Directory Pointer Selector: 00b 값을 더해서 덤프한 후,

lkd> !dq 207e43000 + (0b * 8) L1
#207e43058 0a000002`07e44863

// PDPE의 12 ~ 51 영역이 가리키는 Page Directory == 207e44000

마지막으로 "Page Table Selector: 124" 값을 더해서 덤프해 보면,

lkd> !dq 207e44000 + (0x124 * 8) L1
#207e44920 8a000001`302009e3

// PDE의 12 ~ 51 영역이 가리키는 Page Table == 130200000

위의 값이 나왔는데요, 이번엔 저 단계가 끝입니다. 왜냐하면 하위 12비트에 해당하는 0x9e3을 플래그로 분석해 보면,

// 0x9e3 == 1001 1110 0011

0: Present (1)
1: Read/Write (1)
2: User/Supervisor (0)
3: Write-through (0) 
4: Cache disabled (0)
5: Accessed (1)
6: Dirty (1)
7: Page Size (1) // 2MB 페이지 크기
8: Global (1)
9~11: AVL (100)

"L" 비트에 해당하는 Page Size가 1로 설정돼 있으므로 2MB 페이지 크기가 됩니다. 따라서, 130200000 주소를 base로 해서 가상 주소의 마지막 21비트를 더하면,

lkd> ? 130200000 + 19080
Evaluate expression: 5102473344 = 00000001`30219080

물리 주소 00000001`30219080 값이 나옵니다. 실제로 이 값이 물리 주소에 해당하는지 !vtop 명령어로 확인해 보면 됩니다. ^^

lkd> !vtop 0 ffffd282e4819080
Amd64VtoP: Virt ffffd282e4819080, pagedir 00000000007d4000
Amd64VtoP: PML4E 00000000007d4d28
Amd64VtoP: PDPE 0000000207e43058
Amd64VtoP: PDE 0000000207e44920
Amd64VtoP: Large page mapped phys 0000000130219080
Virtual address ffffd282e4819080 translates to physical address 130219080.

정확히 일치하는군요. ^^ 위의 과정을 간단하게 설명하면 이렇게 압축할 수 있습니다.

물리 주소 == (!pte의 마지막 PFN) * page size + offset




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







[최초 등록일: ]
[최종 수정일: 12/14/2024]

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

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  53  54  55  56  57  58  59  [60]  ...
NoWriterDateCnt.TitleFile(s)
12435정성태12/1/202025202Windows: 181. 윈도우 환경에서 클라이언트 소켓의 최대 접속 수 (4) - ReuseUnicastPort를 이용한 포트 고갈 문제 해결 [1]파일 다운로드1
12434정성태11/30/202019030Windows: 180. C# - dynamicport 값의 범위를 알아내는 방법
12433정성태11/29/202017771Windows: 179. 윈도우 환경에서 클라이언트 소켓의 최대 접속 수 (3) - SO_PORT_SCALABILITY파일 다운로드1
12432정성태11/29/202019265Windows: 178. 윈도우 환경에서 클라이언트 소켓의 최대 접속 수 (2) - SO_REUSEADDR [1]파일 다운로드1
12431정성태11/27/202016107.NET Framework: 976. UnmanagedCallersOnly + C# 9.0 함수 포인터 사용 시 x86 빌드에서 오동작하는 문제파일 다운로드1
12430정성태11/27/202018514오류 유형: 686. Ubuntu - E: The repository 'cdrom://...' does not have a Release file.
12429정성태11/25/202018597디버깅 기술: 175. windbg - 특정 Win32 API에서 BP가 안 걸리는 경우
12428정성태11/25/202016740VS.NET IDE: 154. Visual Studio - .NET Core App 실행 시 dotnet.exe 실행 화면만 나오는 문제
12427정성태11/24/202017605.NET Framework: 975. .NET Core를 직접 호스팅해 (runtimeconfig.json 없이) EXE만 배포해 실행파일 다운로드1
12426정성태11/24/202015996오류 유형: 685. WinDbg Preview - error InitTypeRead
12425정성태11/24/202017634VC++: 141. Visual C++ - "Treat Warnings As Errors" 옵션이 꺼져 있는데도 일부 경고가 에러 처리되는 경우
12424정성태11/24/202017949VC++: 140. C++의 연산자 동의어(operator synonyms), 대체 토큰 [1]
12423정성태11/22/202018580.NET Framework: 974. C# 9.0 - (16) 제약 조건이 없는 형식 매개변수 주석(Unconstrained type parameter annotations)파일 다운로드1
12422정성태11/21/202016009.NET Framework: 973. .NET 5, .NET Framework에서만 허용하는 UnmanagedCallersOnly 사용예파일 다운로드1
12421정성태11/19/202015286.NET Framework: 972. DNNE가 출력한 NE DLL을 직접 생성하는 방법파일 다운로드1
12420정성태11/19/202015220오류 유형: 684. Visual C++ - MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
12419정성태11/19/202016108VC++: 139. Visual C++ - .NET Core의 nethost.lib와 정적 링크파일 다운로드1
12418정성태11/19/202018354오류 유형: 683. Visual C++ - error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MDd_DynamicDebug'파일 다운로드1
12417정성태11/19/202016058오류 유형: 682. Visual C++ - warning LNK4099: PDB '...pdb' was not found with '...lib(pch.obj)' or at '...pdb'; linking object as if no debug info
12416정성태11/19/202017150오류 유형: 681. Visual C++ - error LNK2001: unresolved external symbol _CrtDbgReport
12415정성태11/18/202017401.NET Framework: 971. UnmanagedCallersOnly 특성과 DNNE 사용파일 다운로드1
12414정성태11/18/202019520VC++: 138. x64 빌드에서 extern "C"가 아닌 경우 ___cdecl name mangling 적용 [4]파일 다운로드1
12413정성태11/17/202018504.NET Framework: 970. .NET 5 / .NET Core - UnmanagedCallersOnly 특성을 사용한 함수 내보내기파일 다운로드1
12412정성태11/16/202020660.NET Framework: 969. .NET Framework 및 .NET 5 - UnmanagedCallersOnly 특성 사용파일 다운로드1
12411정성태11/12/202017439오류 유형: 680. C# 9.0 - Error CS8889 The target runtime doesn't support extensible or runtime-environment default calling conventions.
12410정성태11/12/202017583디버깅 기술: 174. windbg - System.TypeLoadException 예외 분석 사례
... 46  47  48  49  50  51  52  53  54  55  56  57  58  59  [60]  ...