[ OS ] 2. Limited Direct Execution

 

1. Limited Direct Execution 

저번 강의에서는 가상 cpu를 만들어서 할당해주는 내용을 공부했다. 이번에는 어떻게 하면 성능을 유지하고 접근성을 잘 지키며 CPU 가상화를 구현할까에 대해 공부한다.

 

1.1 Direct Execution

실행중인 프로그램에 대한 제한이 없다면 OS는 가 아무것도 제어할 수 없다. 이는 즉 프로세스가 CPU를 독점하고 있으면 OS가 끼어들 틈이 없다는 의미이다. OS가 프로그램을 적으로 실행하며 우리가 원하는 방향으로 흘러가려면 제한된 작업을 하게 해야하고 시간을 나눠쓰게 해야한다.(독점 X)

---

 

2. Problem #1: Restricted Operations

제한된 작업을 실행하게 하려면 I/O 작업을 해서 disk에 접근하려고 할 때나 CPU가 더 많은 자원을 원할 때 제한을 둔다. 이를 위해 프로세스의 모드를 나눠 권한을 다르게 준다. 

1) User mode

- 사용자 모드에서 실행되는 코드는 수행할 수 있는 작업이 제한된다.

- 작업이 제한되며 예외가 발생한다

2) Kernel mode

- 커널모드에서 실행되는 코드는 원하는대로 할 수 있다.

- OS는 커널모드에서 실행

 

사용자 프로세스에서 권한있는 작업을 수행하고 싶으면 시스템 호출을 하면 된다

- Trap instruction : 사용자 모드에서 커널모드로 가며 권한 수준을 낮춘다.

-Return-from-trap instruction : 커널 모드에서 사용자 모드로 가며 권한 수준을 낮춘다.

 

이렇게 되면 사용자가 너무 쉽게 권한을 높일 수 있지 않을까? 라는 의문이 들 수 있는데 trap handler는 사용자가 원하는 주소로 직접 가게 하는게 아니라 특정 서비스를 요청하게 하여 지정된 system call만 이용하도록 한다. 이를 잘 관리 하지 않으면 해킹이 일어날수도 있으므로 trap handler를 거쳐야만 높은 권한의 작업을 수행할 수 있다.

 

2.2 Limited Direct Execution Protocol

 

단계별로 설명을 해보자면

 

1) boot 과정

먼저 OS는 trap에 대한 내용이 들어있는 trap table를 초기화하고 하드웨어는 syscall handler 의 주소를 기억한다. 

2) 프로세스 생성 과정

OS 가 차례대로 Process control block을 생성, 메모리 할당, 메모리 영역에 명령 로딩, user stack 에 argv/ argc 삽입, kernel stack에 regs/PC 삽입을 수행하고 Return-from-trap를 호출한다. 그럼 하드웨어에서 kernel stack에 하던일을 저장해주고 유저모드로 바꿔주고 main을 호출시킨다.

3) Tranp 과정

프로그램은 main을 실행 시키다가 Trap을 실행시킨다. 그럼 하드웨어에서 trap handler를 불러준다. OS에서 바른방법으로 커널모드에 진입했는가를 확인하고 원하는 systrem call을 호풀하고 다시 Return-from-trap을 호출한다. 그럼 하드웨어가 프로그램으로 돌아가게 해주고 종료할 때 다시 OS로 가서 프로세스의 메모리를 비워준다.

 

이때의 stack이 어떻게 변화하는지 사진을 보겠다

    - loading

    - main

 

---

 

3. Problem #2: Switching Between Processes

OS가 프로세스에 참견할 수 있는 방법은 두가지가 있다.

 

1) system call 호출대기하기

-system call을 호출하면 유저모드에서 커널모드로 바뀐다. 이때 참견가능하다. 대부분의 프로세스들은 자주 시스템콜을 호출한다. 또한 잘못된 작업(0으로 나누기)을 했을 때도  OS로 제어권한이 바뀐다

2) OS가 제어하기

타이머 장치를 통해 주기적으로 interrupt 할 수 있다. interrupt가 발생할 때 프로세스는 사전에 구성된 interrupt를 실행한다. 

 

3.1 Context Switch

컨텍스트 스위치가 일어날 때 현재 실행중인 프로세스의 레지스터 값을 커널 스택에 저장해 놓고 곧 실행될 프로세스를 위해 커널 스택에서 필요한 레지스터를 복원한다. 그러다가 Return-from-trap 명령이 실행되면 시스템이 다른 프로세스의 실행을 재개한다.

 

아래사진은 interrupt 로 인해 context switch가 일어나는 상황이다.

 

위 사진을 단계별로 설명해 보자면

 

1) boot 과정

먼저 OS는 trap에 대한 내용이 들어있는 trap table를 초기화하고 하드웨어는 syscall handler 의 주소와 timer handler를 기억한다. 또, OS 는 interrupt timer을 시작하고 하드웨어에서 시작된다. 

2) interrupt 일어났을 때 

하드웨어에서 interrupt 가 일어났다 A유저의 정보를 A 커널스택에 저장하고 커널모드로 변경하여 trap handler를 호출한다. 

3) 스케쥴링, context switch

OS 에서는 상황을 보고 context switch를 할지 고민을 하다가 waiting 중인 process B를 보고 하기로 결정한다. A 커널의 내용을 A 커널 스택에 저장하고 사전에 저장되어있던 B커널 정보를 B커널 스택에서부터 꺼내온다. A 유저모드에서 B 커널 모드로 context switch를 발생시키고 Return-from-trap를 호출한다. 

4) interrupt에서 돌아가기 

하드웨어는 B 유저모드 정보를 B 커널 스택에서 꺼내온 후 유저모드로 변경한다.

 

이 때의 스택과정을 그림으로 나타내 본다면