03. 운영체제 구조(1)

안녕하세요. 이번 글은 운영체제 구조에 관한 글입니다. 이번 글부터는 Content부터 소개를 좀 하고 들어가겠습니다. 지난번 작성한

 2021.10.24 - [학부공부/운영체제] - 02. 운영체제 역사

02. 운영체제 역사

포스팅을 보니 조금 난잡하더라구요. 

 

Contents

 

System Structure

OS design principle

• Mechanism
• Policy

Methods for operating system design

• Layering
• Modularity

Kernel designs

• Monolithic kernel
• Micro kernel
• Hypervisor

 

---

03.01. System Structure

운영체제는 매우 규모가 크고 복잡하죠. 거기다가 하드웨어의 발전속도를 보면 확장성은 매우 중요한 이슈입니다. 좋은 설계를 통해 수정과 디버깅이 쉬워질 뿐만 아니라 유지 보수, 확장을 이룰 수 있는 것이죠. 다만, 디자인 decision에서 절대적인 것은 없습니다. 목적에 따라 달라지는 것이죠. 우리의 노트북에 슈퍼컴퓨터의 OS는 그닥 좋은 선택이 아닐 겁니다.

 

OS design priciple

HOW? 어떻게 만들 것이냐를 결정해야 할 시점입니다.

 

Mechanism & Policy

 

Mechanism과 Policy 구별하여 우리는 모듈화하여 좀 더 쉽게 설계에 접근할 수 있죠. 분할정복한다고 생각하시면 됩니다. 큰 문제를 푸는 좋은 방법 중 하나이죠.

 

 

03.02. Methods for operating system design

Layering은 OS의 복잡도를 낮추기 위한 방안 중 하나죠. 계층을 나누는 것입니다. 각 계층은 인접한 계층끼리만 통신 할 수 있죠. 이는 장점이자 단점인데요. 뭘까요?

장점 : 설계의 복잡도를 낮출 수 있음

ex) A/B/D 계층에서  C 계층을 집어 넣을 때, B와 D가 제공하는 Syntax와 Semantics를 잘 맞추어주면 A는 상관 없음. 또는 B를 대체할 C계층을 집어 넣을 때도 마찬가지.

 

단점 : Overhead

여러분은 코딩하고 디버깅하다보면 뚱딴지 같은 곳에서 문제가 발생했다고 가리킬 때가 많습니다. 우리는 구글링을 통해서 열심히 검색할 따름이죠.. B의 문제인데 A 오류라고 토해내는 것이 개발자들에게는 참 골칫거리입니다. 커널 구조는 그런 것을 해결하기 위한 approach입니다. 또한 Abstraction을 적용하기 어려운 part에서는 abstraction을 보완할 수 있도록 만들어줍니다. abstraction이 빈약하면 그만큼 code가 정돈되지 않을 수 있습니다. 그래서 네트워크 코딩 쪽에서 많이 적용되고 있죠.

 

하지만 그럼에도 불구하고 우리는 A/B/C Later에서 A/C direct connection case를 만듭니다. 우리가 세운 principle을 지키기 위해 희생해야 할 overhead가 너무 큰 경우죠. Case by Case라 할 수 있습니다.

 

Modularity는 A/B/C와 같이 계층적인 것이 아니라 A, B, C 이렇게 나뉘죠. 접점이 arbitrary합니다. 장점은 접점이 넓으니까 편하죠. 그 말은 보안관점에선 취약점이 증가한다는 말이기도 합니다.

 

Kernel designs

커널 모듈들

DKI : Kernel interfaces HAL : Hardware Abstract Layer

디바이스

80년대에는 하드웨어가 새로 출시되면 커널을 다시 컴파일하거나 하드웨어를 지원하는 버전을 찾아야 했죠. 이유는 DKI와 같은 인터페이스가 없었기 때문입니다. 90년대 후반부터는 이러한 인터페이스를 exposed시켜서 그거에 맞게끔 프로그래밍만 한다면 어느 디바이스나 붙일 수 있게 되었습니다. 우리는 아주 호환이 잘 되는 시대를 맞이하게 된겁니다.(아주 좋은 겁니다. 호환이 안된다면 우리는 창고에 수많은 기계장치와 케이블들을 쌓아두고 살지도 몰라요.)

 

CPU 실행 mode

우리는 본격적으로 kernel을 설명하기 전에 실행모드라는 것을 이해할 필요가 있습니다. 우리는 소프트웨어와 하드웨어를 이미 이해하고 있습니다. 개발자들은 시간이 지나면서 하드웨어 접근을 제어할 필요성을 느끼기 시작했습니다. 이전에 배웠던 내용인 멀티프로그래밍을 생각해볼까요? switching을 user가 하게 된다면 어떻게 될까요. 누군가는 '싫어! 내가 계속 CPU쓸거야'라고 하지 않을까요.  즉 CPU의 Execution mode와 application의 execution mode를 이원화할 필요성을 느낀 것입니다.

 

System protection

 

실행 모드의 권한에 따라 접근할 수 있는 메모리와 명령어가 다릅니다. Intel의 경우 ring 0~3이라는 것을 두었죠.

[그림 1] Intel ring

이 내용을 아래의 표로 정리해 보았습니다.

Mode
Kernel mode	OS가 실행 특정 명령어(I/O 장치 제어 명령어) 실행 및 Register 접근 가능
User mode	Application이 실행

만약 User mode에서 메모리에 접근한다면 하드웨어적으로 failure합니다. 뭐 그냥 miss시키는 거겠죠.

 

그럼 mode를 어떻게 바꾸냐라는 질문을 당연히 하시게 될텐데요. User mode에서 실행중인 application이 Kernel mode의 권한이 필요한 서비스를 받기 위한 방법이 필요합니다. 

 

 

System call

User mode에서 kernel mode로 진입하기 위한 통로입니다. linux라면 /usr/src/linux-버전/kernel에서 시스템 콜 함수의 구현을 볼 수 있습니다. 목록은 /usr/src/linux-버전/arch/x86/entry/syscalls의 syscall_64.tbl에 있습니다. 수백개의 시스템 콜이 있을 겁니다. Open, Write...

 

[그림 2] System call

시스템 콜을 이해하기 좋은 그림이 있어 첨부하였습니다. 출처는 이제 다들 아시죠?(출처에 관해서는 본 카테고리의 첫번째 포스팅을 참고하시면 됩니다. 그리고 저작권 정책 페이지를 읽어봐주세요.) 시스템 콜을 하면 해당하는 index가 있고 system call table로 가서 해당하는 함수를 찾습니다. 그리고 함수의 implementation대로 실행합니다.

 

여기서 System call을 함수라고 하였는데요. 그렇다면 argument가 있겠죠. 예를들면 뭘 쓰라는 건지 뭘 읽으라는 건지 알아야 하잖아요, 그래서 그걸 우리는 통로가 필요합니다. 컴퓨터 구조과목을 배우셨다면 이정도는 쉽게 눈치채실 겁니다. 디스크는 속도가 너무 느리죠. CPU의 register를 사용할 때가 된겁니다. 거기서 register의 제한된 capa까지 고민하셨다면 아주 훌륭합니다! 흘러 넘치는 것은 Stack, 즉 메모리를 사용하면 되겠죠. 요것은 또 보안을 공부하시는 분들이라면 흥미를 느끼실만한 부분일 것입니다. 버퍼오버플로우를 발생시킨다면..? 뭐..이제 이런 것 정도야 요즘 시스템이면 다 막겠지만요.

 

일반적인 커널의 구조는 아래와 같습니다.

[그림 3] Kernel

 

원래는 이쯤하고 Monolithic kernel부터 시작해서 본격적으로 kernel design에 대해 설명해야 할 시간인데요. 몇가지 이슈만 추가적으로 살펴보고 kernel design 내용은 글이 너무 길어져서 한번 끊고 가겠습니다.

 

그렇다면 우리는 mode를 어떻게 인식할까요? 결국 System call은 application이 호출하는 것입니다. mode를 switching하는 것은 별도의 instruction이 있습니다. 이전에는 인터럽트를 발생하여 커널에서 핸들러가 이를 감지하는 방식이었는데요. 사실 가장 빠른 방법은 instrcution이죠. 하드웨어에 그냥 밀어넣으면 되니까요. 즉, 하드웨어가 switching하고 그 다음에 커널이 그것을 받아서 확인하는 방식입니다. 보안분야에서는 커널이 이걸 확인하는 부분의 취약점을 찾아서 공격하겠죠? 이러한 공격은 에플리케이션 취약점 공격보다 하위레벨이라서 시스템에 더 치명적일 수 있습니다.

 

 

오늘은 design decision인 부분이라 많은 궁금증이 생길 수 있는데요. 댓글로 남겨주셔서 함께 고민해보면 좋을 것 같습니다.