Resource Protection & System Call

자원보호와 시스템콜

 

Kernal

- 운영체제에 상주하는 메모리

- 대다수 C, 어셈블리 언어로 작성됨 (빠른 속도를 위해)

- 함수의 집합으로 구성됨

- 기본적인 메커니즘을 제공 (프로세스 관리 , 동기화 , CPU 스케줄링 , 메모리 관리 , 디바이스 관리 , 인터럽트 핸들링)

- 시스템 콜을 통해 서비스를 제공함

 

Utility

- System utility or User utiliry

- 디스크는 OS의 일부로서 상주한다. ( 요구시 로드 )

 

Shell

- 특별한 유틸리티. 명령을 제어하는 역할.

 

Dual-Mode

- 최소 두개의 구별되는 모드로 하드웨어의 Support를 제공함.

Kernel Mode / 어떤 OP-code던지 실행가능/아무 제한 없이 어떤 메모리라도 접근 가능/어떤 레지스터든지 접근 가능

User Mode / 권한 있는 OP-code 존재 X / 오직 내 메모리 영역만 접근 가능 / 특별한 레지스터 없음

 

몇몇 명령은 운영체제에 의해서 제한됨.

- 유저는 직접적으로 입출력장치에 접근할 수 없음 ( 권한있는 명령이나 메모리 맵핑을 통해서만 접근할 수 있음 )

- 메모리 상태 관리를 조작하는 명령은 반드시 제어되어야 함 ( page table pointers , TLB load etc..)

 

Machine Instruction Cycle

Fetch -> Decode -> Excute -> Memory -> Write Back

 

Mode Switch(모드 스위치)

- 모드 비트를 0 또는 1로 하드웨어에게 할당

(현재는 주로 0(Kernel Mode) , 1(User Mode) )

- 인터럽트 or 예외가 발생하면 하드웨어는 커널 모드로 스위치함.

- Change Mode Bit 명령은 권한이 있어야 하기 때문.

 

CPU Protection Mechanism

- CPU 독점을 막기 위함

- 보호는 보안이 아님 (예를 들어 무한 루프에 걸린 사용자 프로그램은 OS에 제어권을 반환하지 않음)

- 하드웨어에 타이머 지원(Ex. SMP에 로컬 APIC 필요)

 

System Timer

- PIT(Programmable Interval Timer) 라고 불림

- 주기적인 속도로 인터럽트 구동 -> Hitting Hz(tick) !

- 특정 시간이 지나면, 인터럽트를 발생시킴

- 타이머 인터럽트가 발생하면 , OS에 제어권을 넘김

- 타이머는 권한이 있어야 함. 오직 OS만 로드할 수 있음.

 

절대 시간 & 상대 시간

Absolute Time : 어떤 벤치마크 방식 없이 시간을 나타냄. (2022년 3월) , Unix 시스템은 1970년 1월 이후로부터 초단위의 숫자로 절대시간을 나타냄.

Relative Time : 어떠한 시간을 기준으로 현재 상태를 나타냄. ( 지금으로부터 5초 )

 

Timer Interrupt 예시

Timer Interrupt Handler가

1. jiffies를 업데이트함 -> 2. wall time을 업데이트하고 xtime에 저장함. -> 3. process time을 업데이트함.

(현재 실행하고 있는 프로세스의 자원 사용을 Update 및 time slice를 Update.) quantum(time slice)을 체크함.

 

Memory Protection

MMU ( Memory Management Unit )

- logical한 메모리 주소를 physical한 주소로 번역하는데 도움을 줌.

- 메모리 보호, 캐시 컨트롤 , bus arbitration을 동시에 handling함.

- 메모리 관리 상태를 조작하는 명령

 

I/O Protection

- 모든 I/O 명령은 권한이 있는 명령임.

- 유저가 직접적으로 I/Oㅇ에 접근할 수 없음.

- 사용자가 명령어를 수행하기 위해선 OS Procedure를 호출해야 함.

그렇다면 User Mode 프로그램은 Kernel Mode 서비스를 어떻게 호출하냐 ?

-> 그것이 바로 시스템 콜(System Call)

 

Kernel Enrty Point

유저가 어떠한 이슈에 의해 커널 모드에 들어오는 시점은 인터럽트 / 예외 / 시스템 콜이 있음.

 

System Call(시스템 콜)

- 프로세스가 특정 커널 서비스에 요청한다는 의미로 어플리케이션이 OS와 소통하도록 허락함.

 

시스템 콜의 목적

- 시스템 자원을 보호하기 위해(신뢰할 수 있는 ex.OS 와 신뢰할 수 없는 ex.User 를 반드시 구분해야함)

- 프로그램의 신뢰성을 위해 ( 무한 루프, Buggy Memory 등 )

- 악의적인 유저로부터의 보안성을 위해 ( 권한 없이 OS 및 다른 자원 Read/Write )

 

시스템 콜은 약 200개가 존재함.

portable이 뛰어나고 견고함. 따라서 직접적인 시스템 호출이 아닌 wrapping된 API를 통해 대부분 사용자 프로그램에 Access함.

그렇다면 System Call 대신 API를 사용하는 이유는 ?

-> OS에게 약간의 유연성을 주기 위함.

-> System call은 사용하기 쉽지 않음. 이러한 것들을 사용하기 쉽게 하기 위해 라이브러리를 만듬.

각 운영체제마다 System call이 다름.

가장 일반적인 3가지 APIs

POSIX API / Win32 API / Java API

 

시스템콜의 Type

- 크게 6가지의 카테고리로 그룹화 되어 있음.

Process / Scheduling / Interprocess Communication / File System / Socket(Networking) / Miscellaneous

 

시스템콜 호출 시 유저와 커널 예시.

User Program

- 라이브러리 안에 있는 read() 시스템 콜 함수를 호출함 -> 레지스터 안에 arguments를 생성하거나 user stack에 push함. -> 전용 레지스터에 시스템 콜 number를 배치함. -> 명령을 수행함

 

Kernel

- 시스템콜 인터럽트 핸들러를 실행함 -> 시스템 콜 테이블 안에 있는 sys_???() 커널 함수를 실행함. -> 전용 레지스터를 생성함 -> RETURN_FROM_INTERRUPT를 실행함.

 

System Call Parameter Passing

일반적으로 3가지 방식으로 OS에게 파라미터를 전달함.

1. Register 안에 파라미터를 넘김

2. 메모리 안 block에 파라미터를 저장하고 block의 address를 전달함

3. 프로그램에 의해 파라미터를 stack에 push하고 OS에 의해 stack에서 pop함.

이 때, Block과 Stack 방식은 전달되는 파라미터의 길이에 대한 제한이 없음.