Maystyle :
Admin : New post
Guestbook
Local
media
Catergories
Recent Articles
Recent Comments
Recent Trackbacks
Calendar
Tag
Archive
Link
Search
 
해당되는 게시물 520건
  Windows Internals 다시보기 04 
작성일시 : 2010. 2. 17. 18:37 | 분류 : Windows Server/Kernel

* 아직은 많이 부족하기 때문에 제가 자신이 생길 때 까지 본 글은 제 블로그에 대한 링크만 허용합니다.

가상 메모리에서 실제 메모리로의 변환은 어떻게 일어날까요?

모든 프로세스는 자체적으로 자신이 0000,0000 부터 FFFF,FFFF 까지의 메모리를 모두 쓸 수 있다고 생각하고 실행 됩니다. 자 중요한 점은 모든 프로세스 들이 각각 0000,0000 부터 FFFF,FFFF 까지를 각각 사용한다 생각하며 실행 된다는 점입니다.

예를 들자면 A 프로세스도 0000,0000 ~ FFFF,FFFF B 프로세스도 0000,0000 ~ FFFF,FFFFF 이렇게 사용하게 되는 거죠.그리고 OS는 이 가상의 0000,0000 ~ FFFF,FFFF 의 주소를 서로 겹치지 않게 실제 물리 주소(RAM)로 변경해 줍니다.

이를 위해 OS는 Virtual Address Translation 을 하게 됩니다.

제가 말씀 드린 것처럼 프로세스는 그저 가상 메모리 주소만 사용합니다. 그리고 OS에서 그 가상 메모리 주소를 실제 메모리 주소로 바꿔 주는데, 이 메모리 주소는 10+10+12 의 구조로 되어 있습니다. 10 + 10 + 12 는 각각 페이지 디렉토리 인덱스 페이지 테이블 인덱스 바이트 인덱스라 합니다.

image

물론 자주 쓰는 메모리 같은 경우 해당 페이지 프레임을 저장하여, 위와 같은 2단계의 검사가 동일 페이지 프레임에 대해 지속적으로 발생하는 것을 방지 하기 위해 TLB (변환 참조 버퍼)를 이용합니다.

image

PDE와 PTE에는 무슨 값이 들어 있습니까?

각 PDE 및 PTE의 엔트리는32bit 사이즈를 가지고 있습니다.
아래 그림에서 볼 수 있는 것과 같이 상위 20bit를 이용하여 주소를 표현하고 나머지는 접근 권한 및 Paging 유무 등의 정보로 사용하고 있습니다.

(출처 : 루트킷 윈도우 커널 조작의 미학 P83~P84)
페이지 디렉토리 엔트리
image

위와 같이 페이지 디렉토리 엔트리의 첫 20비트가 페이지 테이블의 베이스 어드레스가 됩니다. 그리고 나머지는 해당 페이지의 속성을 보여주는데, 이중 U가 0이면 해당 페이지 테이블은 커널에서만 접근이 가능함을 나타내고, W가 0이면 해당 영역은 읽기 전용임을 나타내게 됩니다.

페이지 테이블 엔트리
image

앞의 20Bit는 페이지 프래임 번호를 의미하고 나머지 비트는 위에서 설명한 것과 같이 U와 W 비트는 페이지 디렉토리 엔트리와 동일한 역활을 하며, 여기에 더불어 P 비트가 0이면 해당 메모리는 실제 RAM 상에 1이면 페이징 되었음을 의미합니다.

만약 우리가 PTE의 엔트리를 확인 할 수 있다면, 가상 메모리 주소의 마지막 12비트만을 이용하여 실제 메모리 주소를 찾아 갈 수 있습니다. (이에 대한 설명은 나중에 하도록 하겠습니다.)

자 그림에서 CR3란 무엇일까요?
바로 CPU의 CR3 레지스터를 의미합니다. 실제로 이 Directory Base 의 물리 주소 값은 앞에서 설명한 것과 같이 EPROCESS 에 저장되어 해당 프로세스가 로딩 될때 CPU의 CR3 레지스터에 저장되게 됩니다.

PROCESS 81e5db78 SessionId: 0 Cid: 094c Peb: 7ffda000 ParentCid: 00d8
DirBase: 05642000 ObjectTable: e1669348 HandleCount: 109.
Image: notepad.exe

kd> r cr3
cr3=05642000

notepad.exe 프로세스의 가상 메모리를 관리하기 위한 페이지 디렉토리의 물리적 시작 위치가 05642000 라는 것을 알 수 있습니다. CR3 레지스터는 프로세스의 구조체에 저장되어 Context switching 이 일어날 때 마다 다른 CR3가 활성화 되게 됩니다. 이렇게 서로 다른 물리 주소로 부터 PDE 가 시작되기 때문에 모든 프로세스들의 페이지 디렉토리들이 겹쳐지지 않도록 관리가 가능하게 됩니다.

|
  Windows Internals 다시보기 03 
작성일시 : 2010. 2. 17. 18:33 | 분류 : Windows Server/Kernel

* 아직은 많이 부족하기 때문에 제가 자신이 생길 때 까지 본 글은 제 블로그에 대한 링크만 허용합니다.

프로세스는 자신만의 메모리 공간을 가지고 있습니다.

모든 x86 시스템 (일명 32비트 OS)는 총 4G 까지 메모리를 사용할 수 있습니다.
이 4G의 메모리를 0000,0000 부터 FFFF,FFFF 까지의 주소를 갖게 됩니다.

Windows의 메모리는 유저 메모리 공간과 커널 메모리 공간이 분리 되어 있습니다.

하지만 유저 프로세스는 실제로 0000,0000 ~ 7FFF,FFFF 까지 즉 2G의 메모리 공간만 사용하고 8000,0000 ~ FFFF,FFFF 는 커널 공간에서 사용하게 됩니다.
기본적으로 CPU에는 Privileged level 을 통해 실행 명령어를 제한 합니다. 이를 Ring 이라 부르며 인텔 CPU는 Ring 0 ~ 3 에서 0과 3만을 사용합니다.
그리고 높은 권한이 필요한 명령어인 인터럽트를 시작 및 중지한다든지 하는 일들은 Ring 0에서만 돌아가게 해서 권한을 조정했죠.

그리고 Windows는 여기에 아예 접근할 수 있는 메모리 자체를 분리해 버렸습니다. 보통은 유닉스 계열을 모놀릭 커널이라 부르고 Windows는 마이크로 커널이라 부르는데, 이는 바로 유저 프로세스 메모리 공간과 커널 메모리 공간을 정적으로 분리했기 때문입니다. (빠른 처리를 위해 Win32k.sys 서브시스템 및 TCP/IP등이 커널 모드에 있으니 정확한 의미의 마이크로 커널 운영체제는 아닙니다.)
각 유저 프로세스는 임의로 0000,0000 ~ 7FFF,FFFF 까지 접근하고 동일 Windows OS 즉 커널로부터 서비스를 받지만 커널 메모리 공간인 8000,0000 ~ FFFF,FFFF 까지 접근이 차단되어 있습니다.

image

Windows는 이를 통해 커널의 안정성을 보장할 수 있습니다. 위와 같은 구조라면 Notepad.exe에 문제가 발생하더라도 해당 프로세스는 실행에 문제가 발생하겠지만 이는 커널까지 영향을 줄 수 없고, Iexplorer.exe 및 windbg.exe 까지 영향을 받진 않습니다.

메모리 사용의 효율성을 위해 VAD를 이용하여 메모리 주소를 사용합니다.

image

프로세스는 2G의 메모리를 사용한다고 생각하지만 실제로는 위의 그림과 같이 실제 사용하는 부분만 VAD로 정의 되어 실제 메모리나 Disk에 페이징 파일로 저장되게 됩니다.
다시 말해 메모리 사용를 효율적으로 사용하기 위해 VAD를 이용하여 쓸 공간을 지정해 놓고 쓰게 됩니다.
위의 예에서 확인 할 수 있는 것과 같이 실제로 이 notepad.exe 프로세스는 2G의 메모리를 사용하는 것이 아니라 최대 가상 메모리 48Mb 까지를 이용하고 있습니다.

PeakVirtualSize 48 Mb

이 VAD는 Tree 구조로 되어 있는데 이 VAD의 총 합이 이 프로세스가 사용하는 총 메모리의 합이 됩니다.
아래 그림과 같이 VAD는 자신이 할당 받은 가상 메모리의 범위와 자식 노트에 대한 링크로 이루어져 있습니다.

image

위의 notepad.exe의 예를 보자면 (VadRoot 81afd5f0 Vads 101 …
VAD 81afd5f0가 이 트리의 꼭대기가 됩니다. 그리고 총 101개의 VAD를 가지고 있는 것을 알 수 있습니다.

우리는 각 VAD에 대한 정보를 좀 더 상세하게 확인 할 수 있습니다.
아래는 특정VAD의 Root 주소를 통하여 실제 VAD에 대한 내용을 확인한 결과 입니다. 각 VAD의 ID와 레벨 그리고 시작 번지 및 종료 번지등의 정보를 확인 할 수 있습니다. (출력 값에서 시작 및 종료 주소값은 4K를 곱해야 원래 주소값이 됩니다. 즉 아래의 0x10 번지에서 시작하는 경우 가상 주소는 0x10000 이 됩니다.

kd> !vad 859aad30
VAD level start end commit
85a77c40 ( 5) 10 10 1 Private READWRITE
855e6148 ( 4) 20 20 1 Private READWRITE
85a5e520 ( 5) 30 6f 4 Private READWRITE
855850b8 ( 3) 70 74 0 Mapped READONLY
855e46c0 ( 5) 80 17f 8 Private READWRITE
855b80b0 ( 4) 180 18f 0 Mapped READWRITE
85624410 ( 5) 190 1a5 0 Mapped READONLY
855b7f10 ( 2) 1b0 1f0 0 Mapped READONLY
85621960 ( 5) 200 240 0 Mapped READONLY
855869a0 ( 4) 250 255 0 Mapped READONLY
855b8f40 ( 5) 260 2a0 0 Mapped READONLY
85614778 ( 3) 2b0 377 0 Mapped EXECUTE_READ

|
  Windows Internals 다시보기 02 
작성일시 : 2010. 2. 17. 18:30 | 분류 : Windows Server/Kernel

* 아직은 많이 부족하기 때문에 제가 자신이 생길 때 까지 본 글은 제 블로그에 대한 링크만 허용합니다.

프로세스

프로세스의 특징 위에서 자원 소유의 단위라고 말씀 드렸습니다만, 더 정확히 말해서 Thread가 실행 하기 위해 필요한 모음이라는 표현이 어울립니다. Thread의 동작을 위해서 필요한 메모리 공간이나 리소스를 조작하기 위한 핸들 등은 모두 프로세스를 통해 표현이 됩니다.
image

프로세스는 EPROCESS 구조체를 통해 표현 할 수 있습니다.
아래 그림과 같이 EPROCESS 구조체에는 해당 프로세스의 id 와 현재 실행 되고 있는 다른 EPROCESS 들과의 연결 그리고 주 보안 토큰 및 핸들 테이블에 대한 포인터 등등의 정보를 가지고 있습니다. 실제로 이 EPROCESS의 정보를 보는 것으로 대충의 프로세스의 구조에 대한 이해가 가능합니다.

image

EPROCESS 구조체를 통해 프로세스를 이루고 있는 메모리 공간이라든지 (Dirbase 및 VADs), 엑세스 토큰, 각종 객체를 조작하기 위한 핸들 테이블과 함께 디스패칭 및 스케줄링과 관련된 정보 및 커널에서 동작하는 쓰래드와 관련된 정보들이 저장된 KPROCESS 블록(PCB)과 로딩될 파일 정보 및 메모리 힙 정보 등을 저장하고 있는 프로세스 환경 블록 (PEB) 을 확인 할 수 있습니다. (읽어 주셨으면 하는 부분은 좀 강조를 해봤습니다.)
image

실제 Windbg에서 EPROCESS 의 구조를 확인 할 수 있습니다.

kd> dt _eprocess
nt!_EPROCESS
+0x000 Pcb : _KPROCESS
+0x078 ProcessLock : _EX_PUSH_LOCK
+0x080 CreateTime : _LARGE_INTEGER
+0x088 ExitTime : _LARGE_INTEGER
+0x090 RundownProtect : _EX_RUNDOWN_REF
….

|
  Windows Internals 다시 보기 01 
작성일시 : 2010. 2. 17. 18:27 | 분류 : Windows Server/Kernel

* 아직은 많이 부족하기 때문에 제가 자신이 생길 때 까지 본 글은 제 블로그에 대한 링크만 허용합니다.

근래 몇 일 동안 Windows Internals 5th Edition 을 확보하는 바람에 아주 지루한 시간들을 보냈습니다. 여전히 끝까지 읽는 건 GG 쳐야 되나 봅니다. 하지만 적어도 전보다는 많은 내용이 보이더군요. 역시 아는 만큼 보이나 봅니다.

오늘부터 몇 주 ~ 몇 달에 거쳐서 제가 읽고 이해한 내용을 쓰려고 합니다.
같이 따라  할 수도 있겠죠.

순서는 프로세스로 갔다가 메모리에 대한 설명을 좀 하고 다시 객체로 갔다가 쓰래드 를 거친 후에 인터럽트나 콜게이트 같은 내용 역시 거친 후 마지막으로 커널 메모리 레이아웃 정도로 끝내볼려고 합니다.

참고서적 : Windows Internals / Windows 구조와 원리

제 1장 준비하기

사전 준비 사항

(본 글은 인텔 x86 프로세서 기반의 Windows 20003과 XP 기반으로 기술 되었습니다.)

준비물 : Virtual PC 및 XP 가상 머신, Windbg
가상 Windows XP 머신에 대한 설정
image

커널 디버거 설정
image

그리고 디버깅될 대상 PC의 C:\boot.ini 에 아래와 같이 디버깅을 위한 내용을 추가합니다.
Boot.ini 정보 추가
/debug /debugport=COM1 /baudrate=57600
image 

디버거를 시작하면 아래의 명령어를 차례로 입력합니다.
.symfix > .reload >.reload /user

OS는 사용자 프로그램과 하드웨어를 이어줍니다.

OS는 지금 여러분이 이 글을 보고 있는 지금도 많은 일들을 처리하고 있습니다.
우리가 오피스 프로그램을 열어 문서를 작성하고 저장한다면, OS는 오피스 프로그램의 구동 부터 시작해서 하드웨어인 HDD에 파일을 열고 저장하는 등의 많은 일들을 처리하고 있습니다.

그렇다면 OS는 이런 요청들에 대한 처리를 어떻게 하고 있을까요?

프로그램과 프로세스와 쓰래드

먼저 우리가 실행 하는 프로그램을 들여다 보도록 하겠습니다.

일반적으로 프로그램은 하나 이상의 실행 이미지(.EXE)로 이루어져 있습니다.
아래 그림에서 보는 것처럼 우리가 실행하는 프로그램은 1개 이상의 exe 파일로 이루어져 있습니다.

image

그리고 이 실행 이미지인 exe 파일은 OS 상에서 실행 될때 프로세스가 됩니다. 간단하게 노트패드를 실행 시킨 다음 실행 이미지를 보도록 하겠습니다.

kd> !process        
PROCESS 81e5db78 SessionId: 0 Cid: 094c Peb: 7ffda000 ParentCid: 00d8
         DirBase: 05642000 ObjectTable: e1669348 HandleCount: 109.
         Image: notepad.exe
         VadRoot 81afd5f0 Vads 101 Clone 0 Private 285. Modified 191. Locked 0.
         DeviceMap e16598f0
         Token e19a7d10
         ElapsedTime 00:01:32.386
         UserTime 00:00:00.000
         KernelTime 00:00:00.000
         QuotaPoolUsage[PagedPool] 37608
         QuotaPoolUsage[NonPagedPool] 4136
         Working Set Sizes (now,min,max) (1554, 50, 345) (6216KB, 200KB, 1380KB)
         PeakWorkingSetSize 1740
         VirtualSize 37 Mb
         PeakVirtualSize 48 Mb
         PageFaultCount 2852
         MemoryPriority BACKGROUND
         BasePriority 8
         CommitCharge 715

자 위 내용을 보면 우리는 대충 이 Process 에 어떤 정보가 들어있는지 확인 할 수 있습니다. 먼저 우리는 Image: notepad.exe 를 통해 해당 프로세스가 notepad 라는 것을 알 수 있습니다. 프로세스는 실제 일(Thread)이 동작할 수 있도록 필요한 모든 것들을 모아 놓은 일종의 모음입니다. 이 안에는 보안 식별자 그리고 파일 같은 기타 여러 가지 오브젝트를 접근할 때 쓰는 핸들 그리고 메모리 공간 마지막으로 Thread가 포함 됩니다.

프로세스의 특징 (출처 : Windows 구조와 원리)
- 자원 소유의 단위 : 자신의 이미지 로드와 실행에 필요한 메모리 공간 및 파일, I/O 장치들 등은 프로세스 단위로 할당 받고 관리됨.

쓰래드의 특징 (출처 : Windows 구조와 원리)
- 디스패칭의 단위 : 운영체제로 부터 CPU 자원을 할당 받아 실행 하는 단위

|
  Microsoft Cluster Service (MSCS) cluster verification errors 
작성일시 : 2010. 2. 11. 12:16 | 분류 : SQL Server/Cluster

[현상]
MSCS 상의 SQL Server 2008 설치 시 “Microsoft Cluster Service (MSCS) cluster verification errors” 에러와 함께 설치가 실패

[조치 사항]
해당 내용은 클러스터와 관련된 심각한 오류가 기록되어 있을 경우 설치 프로세스를 중지하기 위해 추가된 기능합니다. 다만 클러스터 호스트 서버의 리부팅과 같은 경우도 오류로 기록되어 곤란한 경우가 많습니다.

간단하게 옵션을 통해서 문제를 우회 할 수 있습니다.
다만 이 옵션을 사용할 때는 해당 에러를 정확히 확인 하고 해결 여부를 확인한 후 진행 하시기 바랍니다.

클러스터에 SQL Server 인스턴스 설치 시 :
Setup /SkipRules=Cluster_VerifyForErrors /Action=InstallFailoverCluster

클러스터에 SQL Server 노드 추가 시 :
Setup /SkipRules=Cluster_VerifyForErrors /Action=Addnode

[기타]
/Action 옵션을 통해 실행 할 수 있는 Action 목록
None
RemovePatch
Uninstall
Install
Upgrade
Patch
Repair
LandingPage
ClusterReport
RunRules
PrepareFailoverCluster
CompleteFailoverCluster
InstallFailoverCluster
RemoveNode
AddNode
EditionUpgrade
Bootstrap
ComponentUpdate
Help
RebuildDatabase
RunDiscovery

|
  유저 모드 심볼 로딩 
작성일시 : 2010. 1. 17. 16:15 | 분류 : Windows Server/Kernel

kd> .reload /user
kd> x notepad!*

kd> !process 81b3a310
PROCESS 81b3a310  SessionId: 0  Cid: 0828    Peb: 7ffd7000  ParentCid: 00d8
    DirBase: 0049a000  ObjectTable: e15f4c10  HandleCount:  60.
    Image: notepad.exe
    VadRoot 81b00b38 Vads 63 Clone 0 Private 151. Modified 17. Locked 0.
    DeviceMap e16598f0
    Token                             e15d7d10
…   

kd> .process 81b3a310
Implicit process is now 81b3a310
WARNING: .cache forcedecodeuser is not enabled
kd> .cache forcedecodeuser

Max cache size is       : 1048576 bytes (0x400 KB)
Total memory in cache   : 0 bytes (0 KB)

kd> .reload /user
Loading User Symbols
.........................
kd> x notepad!*
010011a4 notepad!_imp__DestroyWindow = <no type information>
010010a8 notepad!_imp__GlobalUnlock = <no type information>

|
  LPC 통신 
작성일시 : 2010. 1. 8. 15:24 | 분류 : Windows Server/Kernel

LPC 통신 이란 프로세스와 커널 간 혹은 프로세스들 간에 LPC 메세지라고 하는 데이터 블럭을 이용한 고속 통신을 말합니다.

- LPC 통신 방식 (출처 : http://www.zezula.net/en/prog/lpc.html)

image 
image

|
  디버깅? Com port cable? 이런거 필요 없어&hellip;! Virtual PC 를 이용한 디버깅! 
작성일시 : 2010. 1. 8. 00:19 | 분류 : Windows Server/Kernel

Microsoft의 Sankim 님께서 이전에 http://blogs.technet.com/sankim/archive/2007/08/20/remote-live-debugger.aspx 통하여 Windows Server의 라이브 디버깅에 대한 소개를 해주셨습니다.

하지만 스터디를 위하여 컴퓨터 2대와 Com 포트 케이블을 이용하는건 쉽지 않습니다. 
그래서 쉽게 Virtual PC를 이용한 디버깅 방법을 소개해 드립니다.

물론 그냥 Windbg의 로컬을 선택하여 디버깅을 할 수 도 있습니다.
바로 아래 그림과 같은 방법이죠…^^

하지만 이 경우에는 OS 들이 동작 중이기 때문에 자세한 Callstack 등을 들여다 보기에는 한계가 있습니다.

그래서 Virtual PC를 이용하는 방법을 소개해 드립니다.
Virtual PC의 Com port를 이용하는 거죠.

자료를 직접 작성할려구 했지만 좋은 자료가 너무 많아서 링크로 대신합니다…^^
http://www.driveronline.org/bbs/view.asp?tb=tipbbs&no=42&GotoPage=1&re=p
http://blogs.technet.com/marcelofartura/archive/2007/06/20/tip-kernel-debugging-a-vpc-server.aspx

|
 Prev   1   ···   11   12   13   14   15   16   17   ···   65   Next