Limited Direct Execution

Direct Execution

응용프로그램이 실행할 때 모든 권한을 다 주는 것

문제점 : 프로세스가 여러개가 돌면 불가능함

OS

Program

[프로그램이 실행되기 위한 기본 환경 세팅] Create entry for process list - entry = PCB 프로세스를 제어하기 위해 PCB를 생성한 후 process list에 넣기 Allocate memory for program 프로세스가 사용할 메모리 영역 할당  Load program into memory  실행을 위한 instructions 로딩( 메모리 적재) complie 한 exe 파일은 storage에 저장되어 있기 때문임 Set up stack with argc/argv 응용 프로그램이 실행되기 위한 user stack만들기 (argc/argv를 넣어줌) - 응용프로그램에서 다루는 stack이 아님 Clear registers 레지스터 초기화 Execute call main() program counter가 main address 가리킴 Free memory of process 프로세스 메모리 제거 (free)  Remove from process list PCB를 process list에서 제거

Run main() Execute return from main()  리턴을 통해 함수가 종료됨을 알려줌

>> 환경 설정 및 끝나고 처리해주는 역할만 하는 OS (어떠한 제약 사항도 주지 않음)

* process list : PCB들이 Linked list에 들어가 있음

* CPU는 storage에 있는 명령어를 실행시킬 수 없음 (실행 시키기 위해서는 storage에 있는 것을 memory로 옮겨야함)

• 자원의 독식을 관리할 수 없음 - 자원 분배를 할 수 없음
• 잘못된 실행을 막을 수 없음

*CPU 자원이 존재해야만, 감시할 수 있지만, direct execution의 경우, cpu자원을 main이 독점하고 있음

∴ main()을 call 한 이후, OS가 확인하는 매커니즘이 필요함

매커니즘은 policy로 구현될 수 있음

Policy (OS 정책)  

- Restricted operation 

- time sharing

 

 

Restricted Operation (Privileged operation)

 ex)

- 디스크로부터 읽기 or 쓰기 → 데이터 오염 발생 가능

- system resource에 접근하기 (CPU or Memory) - CPU는 항상 부족하고 비싼 resource이기 때문에 응용프로그램이 greedy하게 가져가고자 함 → OS는 이를 fair하게 분배해 주는 역할을 해야함

 

Q. Restricted operation을 어떻게 구현할 것인가?

- 제한되었다고 아예 못하게 하면 안됨

- 제한된 통로(통제된 환경)를 통해서만 실행되도록 해야함

 

[Hardware] Processor Modes 

CPU에서 제공하는 여러가지 모드 → OS는 가져다가 사용하는 역할을 할 뿐임

 

https://en.wikipedia.org/wiki/Protection_ring

 

User mode

• 권한이 가장 낮은 instruction만 사용이 가능함
• restricted operation을 사용할 수 없음 → 낮은 레벨의  instruction만 사용가능함

Kernel mode

• OS는 kernel mode로 돌아감
• restricted operation을 아무 문제 없이 사용할 수 있음

System Call 

응용 프로그램이 privileged operation을 하고자 호출 하는 것

시스템 콜 함수의 내부 : library 함수의 rapper 함수 → trap instruction을 부름

trap instruction : user → kernel

return-from-trap instrcution : kernel → user

Q. trap instrcution으로 운영체제에 접근하면 무엇을 보호할 수 있는걸까?

A. privileged operation이 어디에 존재한다고 명시하는 것이 아니라, 정해진 trap table 을 통해서만 접근할 수 있음

즉, 운영체제의 주소를 가지고 어디로 접근할지 명시해주는 것이 불가능함

trap은 임의의 주소에 저장되어 있는 것이 아니라 trap table로만 접근이 가능하다

 

Trap table

• trap instruction은 오직 함수 번호만 명시할 수 있음
• 그 외의 임의의 함수는 절대 부를 수가 없다 / 운영체제 내부의 주소에 접근할 수 없다
• OS는 trap으로 들어올 수 있는 system call들을 잘 정의해 놓아야함
• trap handler : 운영체제 내부에서 권한 검사를 함
• 부팅될 때, trap table을 초기화 → 하드웨어에게 테이블의 위치를 알려줌 

0	함수 포인터가 저장되어 있음 (함수의 시작 주소)
1	trap handler 함수를 저장해놓음
2

각각 어떤 함수를 가리키고 있음 

 

system call 을 담당하는 trap table

모든 system call을 우선적으로 담당하는 trap handler가 존재 

1. system call 호출 시 trap발생 
2. system call 을 우선적으로 담당하는 trap handler를 실행시킴 (Linux 0x80)
3. 몇 번 system call 을 호출하는 것인지 확인 후 약속된 register에 저장함 
4. system call table을 참고하여 system call 함수를 실행시킴

 

OS (kernel mode)	Hardware	Program
Intialize trap table trap 테이블 초기화	Remember address of trap table
Create entry for process list Allocate memory for program Load program into memory Set up user stack with argc / argv Fill kernel stack with regs/PC
Return-from-trap Handle trap trap 번호를 보고 그 번호가 process에 합법적인지 판단 후 syscall 을 호출함 Return-from-trap Free memory of process Remove from process list	Restore regs from kernel stack Move to user mode kernel → user jump to main (PC가 user stack) Save regs/PC to kernel stack CPU가 자동으로 해줌 끝나면 다시 user로 돌아갈 것을 대비 Move to kernel mode user → kernel Jump to trap handler Restore regs from kernel stack Move to user mode Jump to PC after trap user context 저장 - 위와 같음	Run main() Call system call Trap into OS Return from main() Trap

trap : user/kernel switch

stack

 

Q. trap 에 의해 진입한 것이 아닌데, 초기 설정 이후 return-from-trap 하는 이유는?

A. 이름에 연연하지 않고 기능만 생각하기 

 

* 다시 user로 돌아가기 위해 kernel 스택에 정보를 저장함 (하드웨어가 컨텍스트 정볼르 저장) - 끝나면 pop 해줌 

 

[ 맨 처음 return-from-trap ] 

OS가 미리 kernel stack에 user regs/PC (아무것도 없는 regs와 main의 시작을 가리키는 PC)를 넣어줌

이유 : OS가 해주는 역할이 원래 하드웨어적으로 trap에 의해 실행되어야 하지만, return-from-trap을 trap에 의했다고 생각하고 자연스럽게 해주기 위해서이다 (trap이 없엇는데, OS가 인위적으로 넣어주는 것)

 

Time sharing

운영체제가 간섭할 수 있는 시점이 더 많이 필요함 >> 해결 : time sharing

지속적인 감시가 필요하기 때문에, 어느 시점에 os가 관여하게 할 것인지 해결할 수 있음

Cooperative Approach ( 운영체제가 간섭할 수 있는 시점 )

• Wait for system calls - 시스템 콜이 생길 때 커널 모드로 진입함 
• Wait for errors - 오류가 나면 커널이 cpu를 얻을 수 있음 ex) 0으로 나누기 / segmentation fault

Non-Cooperative Approach

• OS가 control을 받기 - timer interrupt

Context Switch 

현재 프로세스의 context저장 → 실행할 process context 환원

이 역할을 해주는 것이 return from trap이다

 

OS (kernel mode)	Hardware	Program
Intialize trap table trap 테이블 초기화 Start interrupt timer timer 초기화	Remember address of rap table & timer handler Start timer (interrupt CPU in X ms)
Create entry for process list Allocate memory for program Load program into memory Set up user stack with argc / argv Fill kernel stack with regs/PC		A : running B : ready
Handle trap timer interrupt handler (OS) > 스케줄러 Call switch() routine Save Kregs(A) to k-stack(A) or pcb restore Kregs(B) to k-stack(B) * 이 때 아직 Address space는 A switch to k-stack(B) Return-from-trap (to B)	Timer interrupt Save Uregs(A) to k-stack(A) Move to user mode kernel → user jump to trap handler Restore Uregs(B) from k-stack(B) Move to user mode Jump to B's PC	Process A Process B

A ~ B로 넘어가는 사이 : A의 처리가 끝난것은 아니지만, B가 실행하기 전 - OS가 점유하는 상태