OS를 알아보자 2편. Protection & Isolation, Sharing

OS를 알아보자 1편 - Abstraction 에서 이어지는 글 입니다.

OS의 Key Roles 중 abstraction에서 1편에서 다뤘으니 오늘은
다른 두 요소를 살펴보기로 한다.

Protection & Isolation

os 도 software 이고, os가 담당하는 schduler, memory manager, file system, device driver 들 또한 software 이다.

위의 그림처럼 하드웨어를 기반으로 돌아가고 있는게 초기의 모델이었다고 한다.

허나 악의적이거나, 버그가 있는 Application이 hardware 자원을 독식(혼자서만 사용) 하려하면 어떻게 할까?
또는 특정 application이 os system에 접근하여 read/ modify 하려는 문제를 방지할 수 있어야한다.

Timer Interrupt

우선 특정 application 이 cpu를 독점하여 infinite loop를 막고자 OS는 Timer Interrupt를 발생시킨다.
한 프로세스가 cpu를 점유한 일정 시간이 되면 interrupt를 발생시켜 control을 OS가 다시 가져오게 된다.
iterrupt 가 발생하면 해당 프로세스는 대기 상태인 Ready Queue에 들어가게 되고 해당 프로세스보다 우선순위가 높은 프로세스가 있다면 해당 해당 다른 프로세스도 cpu를 점유할 수 있다.

// thread.c
void thread_sleep(int64_t ticks){ // current 를 sleep리스트에 저장하고 block 시켜줌
	struct thread *cur;
	enum intr_level old_level;

	old_level = intr_disable();	// interrupt off
	cur = thread_current();

	ASSERT(cur != idle_thread);

	cur->wakeup = ticks;	// 일어날 시간을 저장
	list_push_back(&sleep_list, &cur->elem);	// sleep_list 에 추가
	thread_block();		// block 상태로 변경

	intr_set_level(old_level);	// interrupt on  
}

PintOS에서도 이를 확인할 수 있었는데, 특정 시간에 iterrupt 를 발생시키며 실행 중인 current thread를 sleep_list에 넣으며 cpu를 더 이상 점유하지 않게 된다.

Privileged Instruction

하드웨어는 mode bit를 제공하는데, 해당 bit에 따른 privilege 구분을 시켜놓았다.
Kernel Mode, User Mode를 분리 해놓은 것 인데, instruction을 실행 할 때 해당 instruction을 수행 할 수 있는 mode인지 체크하게 된다.
인텔, 제조사에서 privileged 로 실행 되어야할 instruction들을 정해놓는다.

Memory Protection

또한 OS는 OS code, data 들이 있는 OS만의 privileged memory 를 갖고 있는다. 이를 application(user mode) 에서 접근하게 되면
cpu가 이를 인지하고(이거까지 다 sw로 해결하면 너무 느리니까) exception을 발생시키고, 이 상황을 커널에게 전달하면 커널의 exection handler 에서 application을 kill 하는 등의 처리를 하게 된다.

virtual address, physical address 를 나눈 이유들 중 하나도 아무 주소나 접근하게 되었을 때 해당 주소를 접근한게 커널이냐, 유저냐 한번 확인해주고 실제 메모리에 접근을 허용할지 말지 체크한다.

(필기 끄트머리가 조금 보이는군요..)

이렇게 Timer Interrupt, Privileged Instruction, Memory Protection 으로 application들로부터 os를 구분함으로서 OS를 Protect하게 되었습니다.

그럼 이제 application들 간에 다른 application의 data를 read하거나 modify 시켜버는 이슈가 발생하지 않도록
각 application을 어떻게 분리하였는지 살펴보겠습니다.

- Isolation of memory

프로세스 A가 가상메모리 주소 x에 접근하고 프로세스 B도 가상메모리 주소 x에 접근한다면 둘은 같은 메모리를 참고 하고 있는 것일까?

우선 각 프로세스는 각각의 가상메모리를 갖고 이를 OS가 실제 물리메모리에 mapping을 시키는 것이기에 가상 메모리의 주소가 같더라도 os의 mapping에 따라 다른 물리 메모리를 참고하고 있을 경우가 높다.

왜 그럼 필자는 다른 물리 메모리를 참고하고 있다. 라고 확정적으로 말하는 것이 아닌 경우가 높다고 하는걸까? 그렇지 않는 경우도 있는것 인가?
그럼 같은 두 프로세스가 같은 가상메모리 주소에 접근했는데 실제로도 물리메모리에서 같은 메모리영역(frame)을 공용으로 사용하는 경우도 있을까?

가상메모리가 실제 물리메모리를 효율적으로 사용하게 하는 이유 중 하나는, 각 프로세스가 각 가상메모리에 메모리에 할당하고 사용하지만 실제 물리메모리에는 하나만 mapping하고 이 하나만 mapping한 영역을 두 프로세스가 함께 공유할 수 있기 때문이다. 같은 라이브러리를 사용한다던가 등의 중복되는 영역이라면 각자 할당해서 각각 다 물리 메모리에 매핑하는 것이 아니라 이를 공유한다.

본래의 주제로 다시 돌아가자면, 각 프로세스가 같은 가상메모리 주소에 접근하여도 os가 다른 메모리주소에 mapping을 시켜버리기에 특정 프로세스가 다른 프로세스의 메모리를 읽거나 수정할 수 없다.

이것이 가능한 이유는 각 프로세스가 페이지테이블 또한 각자 들고 있기 때문이다. context-switching이 진행되면서 프로세스 A가 실행될 때는 프로세스 A의 페이지테이블을 load한 다음 mapping을 시키고, 프로세스 B가 실행될 때는 B의 페이지테이블을 load한 다음 mapping을 시킨다.

isolation of file:

메모리뿐만 아니라 파일 또한 isolation을 시키는데, 특정 프로세스가 다른 프로세스의 file을 읽지 못하게 한다.
file system이 access control을 해준다고 한다.

프로세스가 특정 I/O 를 읽고 쓸 수 없기에 시스템 콜로 커널에 요청하면 커널이 permission check를 하고 instruction을 실행한다.

이렇게, application을 os와 분리시켰고 application 간에도 isolation 시킬 수 있었다. 허나 이렇게 분리시켜놓고 보니 application간에 별도의 프로세스 임에도 communication을 해야하는 경우가 생겼고 이를 IPC(Inter-Process Communicatio)라고 한다. 공유된 메모리 공간을 놓고 쓰게 되는 Shared memory 방식과 Message passing 방식이 있다. 빠르고, 데이터가 많이 왔다갔다한다면 Shared Memory, 왔다갔다 하는 데이터가 적고 구현이 쉬운 방식은 Message passing 방식이다.

Sharing resources

마지막으로 OS의 역할 중 "Sharing resources 를 생각해보자.

필자가 지금 글을 작성하면서 작업 관리자를 열어보았다.

435 개의 프로세스가 8개의 cpu를 돌아가며 점유하고 있다. 435개의 프로세스가 한정된(8개) cpu를 "Share" 하고 있는 것이며, 435개의 프로세스가 16GB의 한정된 메모리를 "Share" 하고 있다.

- Time Sharing

Time Sharing을 하는 대표적인 자원은 CPU이다. 특정 프로세스가 일정시간을 점유한 다음, 다른 프로세스가 일정 시간을 점유하도록 os가 sheduling 한다. (네트워크도 Time Sharing을 한다고 한다!) 관련 키워드: cpu scheduling

- Space Sharing

메모리는 Spage Sharing 의 범주로 나뉜다. 각 프로세스는 각자의 가상메모리를 이용하고 있지만 실제 물리메모리에서는 page eviction, swap in/out 등의 과정을 통해 물리 메모리를 공유한다.