2. Operating System Overview (1)

지난 시간까지 컴퓨터 시스템이 동작하는 방식에 대해 간략하게 배웠고, 오늘은 OS에 대한 개괄적인 내용을 다룰 것이다.

 

Operating System Structure

---

운영체제의 구조

 

Multiprogramming needed for efficiency

CPU가 불필요한 대기를 하지 않도록 하기 위해서 OS가 멀티 프로그래밍을 하도록 관리를 해야한다.

하나의 애플리케이션 만으로는 CPU가 항상 바쁘게 만들 수는 없다.

=> I/O로 인해 어쩔 수 없이 대기하는 시간이 발생함.

멀티 프로그래밍을 위해서는 모든 프로그램이 메모리에 올라와야 하는데, 그러기에는 메모리의 용량이 부족하다.
그래서 멀티 프로그래밍을 위해서는 Virtual memory기능이 지원되어야 한다.

프로세서 Management 입장에서는 여러 개의 프로그램이 있을 때 어떤 프로그램을 지금 CPU가 수행할 것인가 결정할 수 있어야 한다.
그것을 우리는 CPU 스케줄링 또는 Job 스케줄링 이라고 한다.

I/O 발생 등의 이유로 CPU가 기다려야 하는 상황이 발생하면 OS는 CPU가 다른 프로그램을 수행하도록 Switch 시켜주어야 한다.

Timesharing(Multitasking)은 CPU switch를 매우 빈번하게 함으로써 사용자가 여러 프로그램으로 부터 반응성을 얻는 것 이다.

멀티 프로그래밍을 하는데, 굳이 어떤 프로그램을 수행하다가 해당 프로그램이 I/O를 발생시켰을 때만 다른 프로그램을 수행하는 방식으로 동작할 게 아니라, 그걸 조금 더 일반화시켜서 I/O를 발생시키지 않더라도 중간에 다른 프로그램으로 Switch 할 수도 있다.

 

왜 그렇게 해야 하느냐?

모든 프로그램이 조금씩 진도를 나가게 하기 위해서.
즉, 멀티 태스킹을 하기 위해서이다.
만약 그렇지 않으면, I/O가 발생하지 않는다면 하나의 프로그램만 수행하게 됨.

멀티 프로그래밍 기술을 이용해서 멀티 태스킹이 가능하도록 하려면 한 프로그램만 계속 수행되도록 하는 것이 아니라
프로그램마다 수행 시간을 정해두고 그 시간이 지나면 I/O가 발생하지 않더라도 다른 프로그램한테 CPU를 주도록 한다.
그런데 이 시간 간격을 매우 짧게 잡으면 모든 프로그램이 CPU를 조금씩 돌아가면서 사용하면서 멀티 태스킹이 가능해진다.

=> CPU 사용시간을 공유하는 것이 멀티 태스킹

사용자의 입장에서는 모든 프로그램들이 사용자의 움직임에 대해서 즉각적인 반응을 해야 모든 프로그램이 진도가 나가고 있다는 느낌을 줄 수 있다.
=> Time sharing(멀티 태스킹)에서는 응답시간이 충분이 작아야 사용자에게 멀티 태스킹이 되고 있다는 느낌을 준다.

 

멀티 프로그래밍을 위해서는 virtual memory가 필요하다. 왜?

4개의 프로그램을 실행시킨다면, 4개의 프로그램이 프로세스라는 이름으로 메모리에 올라갈 것이다.

얘네가 메모리를 거의 다 사용한 상황에서 사용자가 5번째 프로그램을 실행시킨다면, 5번째 프로그램이 들어갈 메모리 공간이 없다.

그럼에도 멀티 태스킹을 지원하기 위해서는 이 프로그램을 실행시켜 주어야 한다.

=> 이때 기본적인 방법으로 스와핑을 사용할 수 있다. 기존에 올라와 있던 프로그램 중 실행되지 않는 프로그램을 디스크로 내리고 수행할 5번째 프로그램을 메모리로 올리는 것이 스와핑.
=> 그런데 디스크에 자주 접근하다 보면 속도가 매우 느려짐.
=> 필요한 모든 프로세스를 로드하기에 충분한 메모리를 갖는 것이 좋음
=> 그런데 메모리의 크기에는 한계가 있기 때문에 Virtual Memory가 필요하다.

=> 스와핑을 효과적으로 하기 위한 방법으로 Virtual Memory가 사용된다.
=> 실행 중인 프로그램의 전체가 메모리에 올라갈 필요없이, 지금 당장 수행되어야 하는 일부분만 메모리에 올리는 방식 이 Virtual memory의 핵심이다.
=> 각 프로그램이 필요로 하는 공간이 줄어들어 더 많은 프로그램을 올릴 수 있게 된다.

 

Operating System Operation

---

 

Interrupt driven by hardware

하드웨어에 대한 접근은 Interrupt Driven으로 한다. 하드웨어가 Interrupt를 발생시키면 그 Interrupt를 핸들링하는 방식으로 하드웨어를 사용한다.

직접 I/O 디바이스에 접근해서 응답을 받는 방식도 있지만, 예상치 못하게 입력이 들어오는 경우가 있다.

컴퓨터는 사용자가 언제 키보드를 누를지 알 수가 없다.

무작정 키보드가 입력되기를 무한 루프를 돌면서 기다리면 CPU를 사용하면서 무한 루프를 도는 매우 비효율적인 동작을 하게 된다.

입력을 기다리는 루프를 도는 대신 입력이 들어왔을 때 키보드가 Interrupt를 보내게 만들어서 Interrupt가 발생하면 아 입력이 들어왔구나를 인식함.

=> Interrupt를 이용해서 하드웨어 입출력(I/O)을 관리

 

Software error or request creates exception or trap

소프트웨어를 수행하는 과정에서도 I/O와 무관하게 지금 수행되는 소프트웨어를 중단하고 긴급하게 처리해야 할 일이 발생할 수 있다.

 

어떤 프로그램을 수행하다가 에러가 발생했다면?

예를 들어 0으로 나누는 연산이 발생하면, 지금 하고 있는 일을 중단하고 그 에러 먼저 처리해주어야 한다.

이 에러의 파급 효과가 시스템 전체에 퍼지기 때문에 이걸 막기 위해서 현재 하고 있는 일을 중단하고 에러를 먼저 처리함.

이걸 Exception이라고 한다.

I/O와 상관없이 소프트웨어 실행 과정에서 급하게 처리해야 할 일이 발생했을 때 Exception이 발생했다고 한다.

이때 Exception handling을 통해 처리.

=> Interrupt와 거의 동일한 방식.

 

그런데 왜 이름을 구분지어 놨느냐?

Exception은 I/O 장치가 발생시키는 것이 아니라 프로그램(소프트웨어)에서 발생시키는 것임.

대표적인 예로 page fault (페이지 폴트) exception이 있다.

가상 메모리 주소 중에 메모리에 올라와 있지 않은 주소에 접근하려고 하면 page fault가 발생.

그러면 Exception handler가 디스크에서 해당하는 주소가 포함된 데이터를 페이지 단위로 메모리에 올려두고 리턴한다.

 

Dual mode operation allows OS to protect itself and other system components

• 현재 CPU가 수행하고 있는 코드가 사용자가 작성한 코드인지, OS의 코드인지 구분할 필요가 있음.
• 사용자 만든 프로그램의 코드는 권한이 제한적임. 안전을 위해서.
• 그러나 OS 코드는 안전한게 보장되어 있기 때문에 권한을 많이 준다(하드웨어 직접 접근 권한도 있음)

 

CPU는 어떻게 현재 수행중인 코드가 사용자 코드인지 커널 코드인지 구분할까?

• Mode bit을 사용해서 현재 수행중인 코드의 모드를 구분한다.
• 프로그램을 처음에 실행할 때는 Mode bit를 user mode로 세팅.
• 그러다가 사용자 코드가 System Call을 호출하면 Mode bit를 kernel mode로 전환.
• 그때부터는 CPU는 많은 권한을 가지고 Instruction을 수행할 수 있게 됨.

 

유저 모드에서 커널 모드로의 전환

• 유저 프로그램을 수행하다가 System call을 호출하게 되면 System call은 커널 영역에 있는 코드이기 때문에 커널 모드에서만 접근이 가능하다.
• mode bit를 커널 모드로 전환하고 System call을 수행한 다음 System call이 끝나고 리턴하게 되면 mode bit를 다시 유저모드로 변경한다.

 

Process (프로세스)

---

프로세스란 무엇인가?

프로세스의 정의는 "실행중인 프로그램" 이라고 되어 있다.

논리적으로는 맞는 말이지만, 조금 더 자세하게 말하면 프로그램을 실행하기 위해 필요한 모든 정보들을 담고 있는 자료구조이다.

프로그램 실행에 필요한 것들을 하나로 묶어서 관리를 한다.
어떻게 묶냐면 이걸 묶기 위한 자료구조를 OS가 제공해주는데 이 자료구조가 바로 "프로세스"다.

이 자료구조에다가 각 프로그램의 코드, CPU를 쓰고있는지 여부, CPU 사용시 우선순위, 메모리 어디에 올라가있는지, I/O를 할 때 필요한 각종 정보들이 무엇인지, 이 프로그램이 접근하는 파일은 뭔지, 이 프로그램이 사용하는 데이터는 뭔지... 등을 저장한다.
그리고 이 자료구조가 메모리에 올라가는 것이다.
그러면 CPU가 그 자료구조로 접근해서 명령어도 가져오고 데이터도 가져와서 연산을 할 수 있게 된다.

사용자가 어떤 프로그램을 실행하라고 명령하면 OS는 프로세스라는 자료구조를 만들어서 자료구조 안에다가 내용을 채우고 메모리에 올린다.
메모리에 올리고 프로세스가 새로 만들어졌으니 CPU 스케줄링을 할 때 이 프로세스도 스케줄링 대상에 포함을 해달라고 등록을 한다.
그러면 언젠가 차례가 되면 CPU가 이 프로그램을 수행하게 된다.

하나의 스레드를 사용하는 프로세스는 program counter가 하나만 있으면 되고,
여러 개의 스레드를 사용하는 프로세스는 각 스레드마다 program counter가 있어야 한다.
=> 각 스레드마다 다른 부분을 수행하고 있기 때문에

 

File System

---

OS는 File이라는 시스템을 관리하고 유저에게 제공한다.

하드 디스크의 저장 공간은 OS가 관리를 한다.

하드 디스크의 공간을 애플리케이션(사용자)에게 그대로 노출할 수가 없다. 하드 디스크의 주소 체계는 매우 복잡한 방식으로 관리되기 때문에 사용자가 프로그래밍을 통해서 접근하게 하면 너무 어려워지기 때문이다.

그래서 OS는 애플리케이션에게 매우 간단한 방식으로 하드 디스크 공간을 사용할 수 있도록 해준다.

OS는 물리적 저장 장치와 사용자 사이에 "파일 시스템"이라고 하는 추상적 계층을 제공한다.

하드 디스크 또는 SSD가 어떻게 생겼는지 신경쓰지 말고, file이라는 공간에 쓰고 싶은 데이터를 쓰면 OS가 알아서 처리를 해준다.
Ex) fprintf, fopen ...  등의 함수를 통해서 파일에 접근 가능

 

File System을 제공하기 위해서는

OS는 하드 디스크의 저장 공간에 대한 정보를 알고 있어야 한다.

현재 하드 디스크의 빈 공간은 어디인지, 채워진 공간은 어디인지 등등.

그리고 I/O가 워낙 느리기 때문에 I/O를 요청할 때 요청 순서를 적절히 조정해서 하드 디스크 헤드의 움직임을 최소화 하고자 하는 방법을 Disk scheduling이라고 하는데, OS는 이러한 매커니즘까지 제공한다.

=> 하나의 I/O 디바이스에 대해 여러 명령을 내릴 수 없는 이유. 디스크 스케줄링에 의해 명령이 뒤섞일 수 있다

 

A라는 데이터가 하드 디스크에서 레지스터까지 올라가는 과정

• 멀티 태스킹 과정에서 데이터는 캐시에 올라가 있을 수도 있고 메인 메모리에 올라가 있을 수도 있는데, 모든 프로그램은 그 데이터의 최신값을 가지고 동작하는 것이 정상이다.
• 만약 A라는 데이터의 값이 3인데, 1번 프로그램이 그 값을 5로 바꿨다.
• 그런데 2번 프로그램도 똑같이 A 데이터에 접근한다면, 원래 값인 3을 접근하는 게 맞을까 바뀐 5를 접근하는 게 맞을까?
  • 당연히 최신값을 접근하는 게 맞다.

OS는 현재 실행되는 모든 프로그램이 접근하는 데이터가 항상 최신 데이터임을 보장해 주어야 한다.

이때 CPU가 여러 개이면 (코어가 여러 개면) 각 프로세서 마다 캐시를 갖고 있기 때문에 상황이 더 복잡해짐.

같은 데이터가 각 코어의 캐시에 동시에 올라가있는 상태에서 어떤 프로세서가 캐시의 값을 업데이트 한다면?

cache coherence problem 발생

이 문제를 어떻게 해결 하냐면, cache coherency protocol은 캐시에 보관된 데이터의 모든 사본이 동일한 값을 가지는지 체크한다.

한 프로세서가 데이터를 수정하면 동일한 데이터의 사본을 갖고 있는 모든 프로세서에게 메시지를 보내 과거의 복사본을 무효화한다.

그리고 메모리 또는 데이터를 수정한 프로세서로부터 업데이트된 데이터를 가져온다.

 

하나의 작업을 여러 대의 컴퓨터에서 동시에 작업하게 되면 같은 데이터에 모든 컴퓨터가 접근을 하게 되고, cache coherence problem보다 더 복잡한 문제가 발생.

=> 이러한 문제를 해결하는 매커니즘도 OS가 제공하고 있음

 

I/O Subsystem

---

I/O 장치는 수많은 회사에서 만들어지기 때문에 그 종류가 매우 다양하다.

마우스만 하더라도 수많은 회사에서 각 회사마다 다르게 마우스를 생산하고 있다.

너무나도 다양한 I/O 장치들의 특성을 사용자는 굳이 구분할 필요없이 사용할 수 있도록 해주는 것이 OS의 중요한 목표 중 하나이다.

=> 사용자에게는 매우 간단하게 구분할 수 있도록 만들어줌.

 

I/O 디바이스가 느리기 때문에 그 느린 것을 만회해주는 소프트웨어적 기능도 OS가 제공한다.

Buffering: 하드 디스크에 저장할 데이터를 버퍼에 임시 저장했다가 한 번에 저장한다. 매번 디스크에 접근해서 데이터를 저장하게 되면 느리기 때문

Caching: 디스크에 있는 데이터 중 일부를 메모리에 올려놓고 사용한다.

Spooling: 어떤 작업이 생성해 낸 output을 다른 작업한테 보낼 때 직접 보내지 않고 중간 단계의 임시 공간(Spool)에 보냄. 그리고 Spool에서 다른 작업이 데이터를 읽어가게 만든다.

Spooling은 프린트를 할 때 많이 사용된다.
hwp 프로그램이 프린터에 출력을 하면 프린터에 직접 데이터를 넘겨주지 않고 OS가 관리하는 Spool이라는 영역에 데이터를 넘겨준다. 그럼 Spool에 있는 데이터를 프린터에 넘겨주는 역할은 OS가 한다.
프린터는 느리기 때문에 데이터를 무작정 보내면 안 됨. 데이터가 손실되거나 변형될 수 있다.

OS가 프린터의 속도에 맞춰서 데이터를 조금씩 넘겨준다
=> 프린터의 느린 속도를 OS가 만회시켜줌

 

Protection and Security

---

Protection과 Security는 어떤 차이가 있을까?

Protection: 권한이 없는 자가 권한이 없는 자원에 접근하려고 하면 막아줌

Security: 악의적인 행동을 막는 것

OS는 권한이 있는 사용자를 구분하기 위해서 유저마다 User ID를 생성.

OS는 UserID를 기준으로 권한을 결정한다!

해당 파일을 만든 사람은 해당 파일에 대한 모든 권한을 가진다.

해당 파일이 만들어질 때 파일을 만드는 사람은 소유자가 아닌 사람들에게는 이런 권한을 주라고 지정을 할 수 있다.

모든 권한을 줄 수도 있고, 읽기 권한만 줄 수도 있고, 접근 자체를 못 하게 할 수도 있음.

 

유저가 프로그램을 실행시키면 그 애플리케이션은 어떤 권한을 가지냐, 유저가 가진 권한을 승계받아서 똑같은 권한을 가지게 된다.

따라서 같은 프로그램이라고 하더라도 실행한 유저에 따라 프로그램이 다른 권한을 가질 수 있다. 그리고 그 권한 내에서 자원에 접근할 수 있게 된다.

 

예를 들어보자

A라는 유저가 로그인해서 hwp 프로그램을 실행시켜 B라는 유저가 만든 hwp 파일을 오픈하려고 하면, 오픈은 A가 실행시킨 hwp 프로그램이 하는 것임.
그러면 해당 프로그램이 가진 권한은 A 유저의 ID가 가진 권한임.

A의 ID가 가진 권한이 B가 생성한 파일을 오픈할 수 있는지는 B가 파일에 대해 설정한 설정을 따름.
다른 사람도 읽을 수 있다고 설정해두었으면 A의 ID로도 파일을 오픈할 수 있음.

그러나 본인 이외에는 오픈할 수 없다고 설정을 해두었다면 A의 ID로 실행시킨 hwp 프로그램으로는 이 파일을 오픈할 수 없음.

Root는 일반 사용자와 다르게 모든 자원에 접근할 수 있는 강력한 권한을 가짐.

 

Privilege escalation

---

User ID가 가진 권한이 일시적으로 상승되는 것

어떤 프로그램을 수행시킬 때, 없는 권한을 획득해야지만 프로그램을 수행할 수 있는 경우가 있음.

A라는 유저의 ID로 hwp 프로그램을 실행시키면 A 유저의 권한으로 실행이 된다.

그런데 프린트를 한다고 하면, 출력할 데이터가 OS가 관리하는 Spool 영역에 쓰여야 한다.

그리고 Spool 영역에 쓰인 데이터를 OS가 프린터의 작업 속도에 맞춰서 보낸다.
=> 여러 프로그램이 동시에 하나의 출력 장치를 사용하려고 하면 데이터가 손실되거나 덮어쓰일 수 있기 때문에 바로 출력 장치로 보내는 것이 아닌 Spool 영역에 보낸다고 앞서 설명했다.

즉, OS가 관리하는 Spool 영역은 사용자의 영역이 아니라 OS의 영역임.

OS가 만든 영역에 사용자 프로그램이 접근하는 건 불가능(Protection으로 인해).

원래는 A의 ID로 실행한 프로그램으로는 OS의 Spool이라는 영역에 데이터를 못 쓰는 게 정상이지만 그러면 프린트를 못 하게 된다.

그래서 프린트를 할 때는 권한을 잠시 상승시켜준다.

OS의 Spool 영역에 쓸 수 있는 권한을 주고, 다 쓰고나면 다시 권한을 가져감.
=> 이게 바로 Privilege escalation.

 

그런데 이것은 매우 위험할 수도 있다.

User ID가 Root의 권한을 갖게 되는 것인데, 그러면 아무 파일을 삭제하거나 접근할 수 있게 된다.

Priviledge가 상승한 틈에 파일에 접근하거나 삭제를 하는 방식의 해킹이 자주 사용됨.