왜 애플리케이션이 Hang 되어도 OS 는 괜찮을까 ?

마이에트 엔터테인먼트Server ProgrammerMicrosoft VC++ MVP

최흥배Twitter : @jacking75

애플리케이션은 유저 모드로 동작 , 시스템은 커넬 모드로 동작하므로 안전 .

시스템과 애플리케이션이 완전하게 분리되어 있으면 애플리케이션에서 시스템의 기능을 어떻게 이용할 수 있을까 ?

어디엔가 유저 모드와 커널 모드의 사이를 중개 하는 것이 있지 않을까 ?

애플리케이션

시스템

하드웨어

유저모드

커널모드

따분할 수도 있겠지만 답을 찾기 위해 짧은 여행을 떠나 보시죠 ~

내용과는 전혀 상관없는 일본 오사카의 야경입니다 . 올해 가고 싶은 곳입니다 .^^;

Windows 의 아키텍처는 프로세서와 깊은 관계가 있다 .

「유저 모드」와「커널 모드」라고 불리는 동작 모드는 그대로 Intel 의 프로세서 (80386~Pentium 4) 가 갖추고 있는 「링 3 」와「링 0 」의 특권 레벨 . 최초는 Intel 프로세서는 「 80286 」의 「프로텍트 모드」 링 번호가 높은 레벨에서 낮은 레벨로 접근 할 수 없음 .

Windows 에서는「링 0 」을 「커넬 모드」 , 「링 3 」을 「유저 모드」라고 부러며 이 2 개의 모드만을 사용한

나머지의 링을 이용하지 않는 이유는 다른 프로세서와의 호환성을 위해

Win32 애플리케이션

Win16 애플리케이션WOW 16

DOS 에뮬레이션

MS-DOS 애플리케이션

DOS 에뮬레이션

Windows 서브 시스템

각종 매니져

그래픽스 드라이버

Window,User,GDI

시스템 서비스 디스패쳐

디바이스 드라이버 , 파일 시스템 드라이버

커널

HAL

유저모드

커널모드

「시스템 서비스 디스패쳐」는 유저 모드와 커넬 모드의 변환을 담당 .

Windows 서브 시스템 블록이 중요 . Windows API 가 구현되어 있다 .

Windows 서브 시스템이 유저 모드와 커널 모드를 묶는 열쇠 .

Kernel32.dll,User32.dll,Gdi32.dll 등의 DLL 을 관리

Kernel32.dll 은 이른바 「 Windows API 」

애플리케이션에서 보면 이름은 「서브」이지만 Windows 서브 시스템은 시스템 그 자체라고 해 과언은 아니다

Windows 서브 시스템 (Win32 API)

Kernel32.dll

애플리케이션

Gdi32.dll User32.dll

실제 애플리케이션이 Windows 서브 시스템 내의 API 를 직접 호출할 수 없다 . 왜냐하면 애플리케이션과 Windows 서브 시스템은 같은 유저 모드 상의 다른 가상 address 공간에 있기 때문

32 비트 프로세서는 프로세서가 가지는 「페이징」기능을 사용하여 물리 메모리 용량과 상관 없이 애플리케이션은 4G 의 메모리 공간을 할당할 수 있음 .

32 비트 프로세서의 페이징 기능은 4G 바이트의 가상 메모리 공간을 하나의 세그먼트(segment) 로 여러개 가질 수 있고 , 그 세그먼트 (segment) 주소와 실제 물리 메모리 주소를 대응표로 관리한다 .

이 대응표를 「페이지 테이블」이라고 부른다 . 그리고 Windows 는 페이지 테이블을 이용하여 가상 머신 마다 4G 바이트의 가상 메모리 공간을 할당해서 그 중 2G 바이트를 애플리케이션 영역 , 나머지 2G 바이트를 시스템 영역으로 지정하고 있다 .

마치 Windows 시스템 안에 4G 바이트의 메모리를 가진 컴퓨터가 여러개 존재하고 있는 이미지가 된다 .

애플리케이션 1

애플리케이션 2

애플리케이션 n

메모리 공간

Windows 시스템의 메모리 공간

시스템애플리케이션 A

시스템애플리케이션 B

가상머신 A

가상머신 B

“ 간단한 구조이지만 애플리케이션에서 다른 애플리케이션이 사용하는 메모리 영역을 침범한다면 ??”

장황한 구조지만 애플리케이션이 사용하는 메모리 영역을 벗어나도 다른 애플리케이션에 영향을 주지 않음 !!!

모든 가상 머신의 메모리 공간에 같은 Windows 서브 시스템을 준비하고 ,가상 머신으로 비동기로 실행되는 API 의 협조를 얻는 것은 어려움 .물론 기술적으로는 가능하지만 메모리 용량의 문제나 기동 시간 등 불리한 점이 많다 .

그래서 애플리케이션의 가상 머신과는 별도로 Win32 API 용의 가상 머신을 진짜 Windows 서브 시스템에서 준비해 두고 , 애플리케이션 측에는 더미 DLL 을 넣음 . 이러한 DLL 을 「 stub DLL 」이라고 부른다 .

그러나 실제로 이 이미지대로 시스템을 만들려고 하면 큰일난다 .

후임병으로 온다면… ..-_-;;

시스템

애플리케이션 A

가상머신 A

시스템애플리케이션 A

가상머신 A

시스템애플리케이션 A

가상머신 A

Stub Dll Stub Dll Stub Dll

Windows 서브 시스템 (Win32 API)

애플리케이션은 자신이 할당할 수 있는 4G 바이트 공간 밖에 액세스 할 수 없다 .

이대로는 다른 세그먼트 (segment) 에 있는 Windows 서브 시스템의 API 는 호출할 수 없게 된다 .

그러나 아직 문제가 있다 !!!

커널 모드로 동작하는 매니저의 하나로

「로컬 프로시저 콜 (LPC) 」서비스

해결은…

가상 머신으로 동작하는 애플리케이션이 실행하는 API 는 Windows 서브 시스템 가운데에 있다 .

그리고 Windows 서브 시스템도 유저 모드로 동작하는 가상 머신이다 .

이 2 개의 가상 머신 사이를 주선하는 것이 로컬 프로시저 콜이다 .

LPC 서비스

가상 머신 가상 머신

가장 중요한 시스템의 중심은 커널 모드로 보호하고 ,

애플리케이션은 유저 모드의 가상 머신에서 실행 .

그 애플리케이션이 호출한 Windows API 는 또 다른 가상 머신에 놓여져 있고

서로 커널 모드가 제어하는 통신 기술로 접속된다 .

이것이 정확하게 애플리케이션 크래쉬가 Windows 의 시스템에까지 영향을 미치지 않는 진짜 이유 .

1 차 출처 :http://itpro.nikkeibp.co.jp/article/Windows/20051111/224393/?ST=win&P=1