[OS] Resource Protection (Kernel Mode, Timer)

Kernel

커널이라는 것은 OS의 부분으로서 항상 메모리에 상주하고 있는 것이다. 대부분이 C 코드로 적혀져 있으며, Assebly Language로 적혀져 있는 것이 많다. 또한 커널 자체는 수많은 함수들로 구성이 되어있다. 이전에 Linux 코드로 Interrupt Handling을 어떻게 처리하였는지 살펴보았는데, Process Management, Synchronization, CPU Scheduling, Memory Management, Device Management, Interrput Handling 등 컴퓨터가 동작하기 위한 주요 메커니즘을 함수로서 제공을 한다. 이러한 것들이 System Call 이라고 한다. 

Utility

커널을 제외한 모든 것을 의미한다. 이를 세분화 하자면 System Utility와 User Utility로 구분할 수 있는데 OS가 Disk에 남아있는 부분이며, 필요할 때 memory에 load된다. 

Shell

Shell은 Special Utility이다. 이는 Utility를 위한 Utility이며, Shell은 Command를 Control하는 역할이 중점이다. 

Dual Mode

대부분의 OS는 HW Support를 위해 두 가지 모드의 Operation을 지원한다. 이것이 바로 Kernel Mode와 User Mode이다. 앞서서 조금 언급했기도 했고, 시스템 프로그래밍 글에서도 언급을 했지만 조금 더 자세히 설명해보겠다.

출처: 위키피디아 https://en.wikipedia.org/wiki/Protection_ring

 커널모드는 어떤 Op-Code를 다 수행할 수 있다. 커널은 하나의 관리자 모드라고 이해하면 쉽다. 그렇기 때문에 메모리에 있는 어떤 공간에도 제약을 받는 것이 아니라 어디에도 접근할 수 있으며, 이는 메모리에 국한된 것이 아니라 레지스터 입장에서도 마찬가지이다. 반면 유저모드는 제한된 Op-Code만 수행할 수 있다. Device, Scheduling Management 등 중요 Resource에 대한 Privileged Operation은 수행할 수가 없다. 따라서 사용가능한 메모리 영역과 Special Register에는 접근할 수가 없다. 위에 있는 그림은 x86 아키텍쳐에서 어떻게 Mode들이 나누어저 있는지를 보여주는 그림이다. 하지만 사실상 Ring 0와 Ring 3만 사용한다고 보면 된다. 

 Instruction들은 OS에 의해 제한되어 있는 것이 있다고 설명했다. 유저가 Disk나 Printer같은 Device에 Direct하게 접근하지 못한다. 따라서 이 Device들에 대한 접근은 System Call 호출을 통해서 Kernel Mode로 진입 후에 컨드롤 하는 것이다. 예를 들어보면 scanf, printf 같은 경우는 User가 일반적으로 사용하는 코드이다.하지만 이는 Kernel Mode에있는 read, write 함수를 mapping하는 것이다. 따라서 이 같은 System Call을 호출해주기 위한 함수이지 이를 통해서 Direct하게 접근하는 것은 아니다. 

Mode Switch

Mode Switch는 이름에서부터 알 수 있듯이 Mode에 대한 전환이 일어나는 것이다. 현재 Process가 어떤 상태인지는 Mode Bit을 통해 확인할 수 있다. 0일때는 Kernel로, 1일때는 User인 것을 확인할 수 있다. Interrupt나 Exception등이 발생하게 되면 HW는 현재 상태를 Kernel Mode로 바꾸게 된다.

CPU Protection

 CPU Protection은 System Level에서 수행이 되야한다. CPU Protection의 주 목표는 CPU가 하나의 User Program을 무한하게 돌릴수 있기 때문에 어떤 프로그램의 수행을 독점할 수 있는 우려가 있다. 예를 들어 무한루프가 걸려버리면 CPU는 그것만 수행할 뿐 나머지는 수행할 수 없어지기 때문에 CPU가 Process를 독점하는 것을 막아야한다. 따라서 System Timer라는 개념이 이때부터 도입이 되었다. 

 System Timer는 주기적으로 Interrupt를 강제로 발생시킨다. 특정 시간 이후 Interrupt가 발생이된다. 일반적으로 Kernel Program은 100ms마다 Interrupt를 발생시키는데, 이에 대한 역수는 주파수이므로 100Hz가 된다. 따라서 헤르츠가 높아질수로 섬세한 Scheduling이 가능하다. 그러나 주의해야할점은 주파수가 높아질수록 mode switch가 더 빈번하게 일어나게 되어 이 switching이 되는 비용을 어느정도 고려해야한다. 이 Interrupt를 Timer Interrupt라고 부른다. Timer Interrupt는 Time Sharing에서 상대시간을 구하기 위한 아주 중요한 Interrupt이다. 또한 Time Slice를 계산해야 하기 때문에 Wall Time(절대시간)을 계산하기 위해서도 필요하다. 

Absolute & Relative Time

 Absolute Time은 진짜 우리가 사용하는 시간이다. UNIX System에서는 1970년 1월 1일을 기준으로 얼마나 경과했는지 확인해준다. Relative Time은 상대시간이다. 특정 Benchmark에 의해 relative한 것이다. 예를 들어 지금으로부터 10초 후 라고 하는 것은 지금이라는 Benchmark로 부터 얼마나 시간이 지났는지 확인하는 것이다. OS와 Kernel 입장헤서는 상대시간이 훨씬 중요하다. 상대시간을 활용해야하는 Interrupt, Syscall들이 훨씬 많다. 

System Timer

 시스템 타이머는 PIT(Programalbe Interval Timer)라고도 불린다. System Timer는 주기적으로 Interrupt를 야기시킨다. 이 주기는 HZ 불리는 시간을 기준으로 한다. 이때 tick, 혹은 jiffies라고 불리는 extern unsigned long volatile 으로 선언된 전역변수를 Interrupt가 Timer Interrupt가 발생할때마다 증가시킨다. System Timer에는 RTC라고 하는 Real Time Clock이라는 절대시간을 파악하기 위한 것도 있는데 이는 nonvolatile device로서 OS가 돌고있지 않을때 절대시간을 파악하기 위한 장치이다. 따라서 이는 HW Clock이며, LINUX에서는 xtime에 저장된다. 

 HZ는 초당 tick의 개수로 다시한번 정의할 수 있다. 또한 jiffies는 tick 자체의 개수라고 다시 할 수 있다. 아래의 그림은 LINUX에서 asm/param.h와 linux/jiffies.h에서 실제로 어떻게 HZ와 jiffies를 가져오는지 보여주는 legacy 코드이다. 

출처: https://github.com/torvalds/linux/blob/master/include/linux/jiffies.h https://github.com/torvalds/linux/blob/master/include/asm-generic/param.h

 따라서 jiffies와 HZ의 변환 관계를 설명하자면 jiffies로부터의 초는 결과적으로 상대시간이므로, 이 시간은 jiffies/HZ의 관계가 성립한다. 또한 8초 후를 나태나고 싶으면 jiffies + 8 * HZ 이렇게도 나타날 수 있을 것이다. 

 이제 Timer Interrupt Handler가 어떻게 작동하는지 모자. 먼저 Timer Interrupt Handler는 jiffies를 += 1해준다. 그러고 나면 wall time을 위해 xtime에 있는 절대시간 역시 업데이트 해주고, Process의 Time을 업데이트 해준다. 이는 Time Slice를 위해 Time Slice도 업데이트 해주는 것이다. 이때 Time Quantum(slice)가 Expire 되었는지 확인한다. 

 위의 그림을 보자. P1에서 Process가 실행하다가 빨간색 동그라미를 만난 시점이 Time Out이 되어 Timer Interrupt가 불러져 Process와 Kernel의 Mode Switch가 일어난 부분이다. 계속 P1과 Kernel에서 Mode Switch가 발생하다가 Kernel에서 P2로 넘어가는 파란색 동그라미는 Context Switch가 일어난 부분이다. Context Switch에 대해서는 뒤따르는 포스팅에서 설명하겠지만 실행하고 있는 Process가 바뀌는 것이다. 일단 지금 당장은 이 그림에서 Process에서는 Mode Switch가 빈번하게 일어난다고 알아두면 될 것이다. 

Memory Protection

메모리는 MMU라는 Memory Management Unit이 담당한다. 이 진화가 결국 Vitrual Memory로 이어지며 이를 통한 Memory Protection이 증가해왔다. 그렇지만 MMU도 결국 메모리 자원을 사용해야 하는 것이기 때문에 TLB라는 캐시 역할을 하는 HW를 사용하게 된다. 이는 OS의 막바지 부분에서 다룰것이다. 

I/O Protection

I/O Protection은 계속 언급했던 Privileged Instruction을 통해 작동한다. 즉 User가 Direct하게 I/O에 Access하는 것이 불가능하다. 따라서 User가 I/O 작업을 하기 위해서는 System Call 함수를 통해 작업을 진행해야한다. 이를 OS Procedure라고도 부른다. 따라서 Kernel에 들어갈 수 있는 포인트는 크게 세가지 Interrupt, Exception, System Call로 분류할 수 있다.

 

이에 대해서는 다음 포스팅에서 System Call에대 POSIX를 예를 들어서 살펴보자.

저작권 문제와 지적은 환영입니다. 

그림의 대한 저작권은 제 블로그에 있습니다. 출처표시 부탁드리니다.

Reference

William Stallings. (2018). Operating Systems: Internals and Design Principles (8th Edition): Pearson.