🌌[Pintos] 2. USER PROGRAMS

두 번째 프로젝트가 끝났다.
지금과 나중의 이해를 위해 과제를 하면서 알게된 것들을 남겨둔다.

Process

프로세스는 "머신(machine)에 대한 추상화" 이다.
조금 더 구체적으로는 CPU / Memory / Storage를 가진 컴퓨터의 추상화이다. 조금 더더 구체적으로는 각 응용프로그램이 이러한 머신의 자원을 독점해 사용하고 있는 것 같은 환상(편한 착각)을 제공하는 추상화이다.

추상화는 디테일을 숨기고, 사용하기 쉽게 API를 제공하는 것.

프로세스라는 추상화를 통해 protection 과 isolation 이라는 목적을 달성할 수 있다.
해당 목적은 하나의 머신에 여러개의 응용프로그램을 실행하기 위해서 설정된 것이다.

목적 달성 방법 : 유저 프로그램이 머신 자원에 직접적으로 접근하는 것을 막는다.
➡️ 유저 모드 / 커널 모드의 구분, 사적 주소공간(각 프로그램의 주소공간을 구분)

프로젝트 1까지의 코드들은 커널과 함께 컴파일 되는, 말그대로 커널 동작의 일부를 구현한 것이었다. 이말인 즉슨, 모든 테스트들이 커널의 일부로서 실행되면서, 모든 시스템 자원과 인스트럭션을 자유롭게 사용할 수 있었다.

이번 프로젝트의 테스트들은, 이러한 무제한 접근이 제한되는 유저 프로그램으로서 핀토스에서 실행된다. 유저 프로그램들은 여러개가 동시에 실행될 수 있어야 하고, 프로그램 하나는 자신이 시스템 자원의 전부를 혼자 사용한다고 가정한 상태로 짜여졌다. 따라서 우리는 프로세스라는 추상화를 제공할 수 있는 커널 코드를 작성해야 했다. 다시 말하자면, 유저 프로그램이 시스템 자원에 접근할 수 있도록 API를 구현하는 작업을 한 것이다.

프로그램 vs 프로세스

• 프로그램은 코드와 데이터가 합쳐진 것. 프로그램은 디스크 상에 목적파일로서, 또는 메모리 상에 세그먼트로서 존재할 수 있다.
• 프로세스는 실행중에 있는 프로그램의 특정 사례.

▶ 프로그램은 항상 어떤 프로세스의 컨텍스트 내에서 돌아간다.

Argument Passing

가장 먼저 구현한 것은 argument passing이다. 위와 같은 상황을 만들기 위해서는 어쨋거나 유저 프로그램을 실행할 수 있어야 하기 때문에, 유저 프로그램을 load하고, command line으로 받은 argument 들을 프로그램에 전달하는 과정을 다뤘다.

큰 그림은,

1. 해당 프로그램을 하나의 프로세스로서 실행하기 위해 그 프로세스의 PCB 역할을 수행할 스레드를 생성하고,
2. 해당 프로세스가 사용할 가상 메모리 환경을 설정해 주고,
3. 해당되는 실행 가능한 목적 파일을 로드한 후,
4. argument를 parsing 하여 프로세스에게 전달한 후 프로세스를 실행한다.

핀토스에서는 하나의 프로세스가 여러개의 스레드를 가질 수 없다. 따라서 하나의 프로세스는 하나의 커널 스레드에 매핑된다.

booting

가장 처음 핀토스가 부팅되는 시점부터 얘기해보자면, 우리는 핀토스 실행을 위해 쉘에 명령어를 입력할 것이다. 명령어는 대략적으로 다음과 같은 포맷을 갖는다.
pintos ${SCRIPT_COMMANDS} -- ${KERNEL_COMMANDS}

가장 첫 테스트인 'args-single' 테스트를 위해 입력할 수 있는 명령어는 아래와 같다.
pintos --fs-disk=10 -p tests/userprog/args-single:args-single -- -q -f run 'args-single onearg'

run 'args-single onearg' 라는 커맨드를 통해, 'args-single' 이라는 이름을 가진 실행 파일을 onearg 라는 하나의 인자를 전달하여 실행한다. 커널 내부 코드에서는 기본적인 부팅 이후 해당 커맨드를 그대로 전달 전달해서 결국 process_create_initd()라는 함수를 호출하게 된다.

process_create_initd()

프로세스에 매핑될 커널 스레드를 생성하고, 스레드 루틴으로 실행 파일을 로드하는 함수와 파일의 이름을 전달한다. 이렇게 하면, 이 스레드가 스케줄 된 다음, 실행 파일을 로드하고 실행될 수 있다.

thread_create()

위에서 언급한 스레드를 실제로 생성하는 thread_create() 함수를 더 살펴보자면,

1. 스레드가 사용할 주소공간을 할당 받고 t = palloc_get_page (PAL_ZERO),
2. 스레드의 정보들을 초기화 하고 init_thread (),
3. 스레드의 식별번호 tid를 할당 받고 t->tid = allocate_tid (),
4. 엔트리 함수 kernel_thread, 스레드 루틴 function, 스레드 루틴에 전달될 하나의 인자 aux를 tf(스레드 구조체 내부의 intr_frame) 에 저장한다.

init_thread () 내부를 보면 스택의 주소가 들어가는 %rsp 레지스터에 커널 스택의 주소를 저장하는 것을 알 수 있다. t->tf.rsp = (uint64_t) t + PGSIZE - sizeof (void *)
유저 프로그램의 실행파일이 로드되는 과정 자체는 커널의 실행이기 때문에, 이런 식으로 intr_frame (여기에서는 tf)를 준비하는 과정이 필요하다.

process_exec()

해당 스레드의 루틴인 initd() 함수를 보면 process_exec() 라는 함수가 있다. 여기에서 code와 data에 대한 가상주소를 설정하는 과정과 실제 실행파일을 로드하는 과정 load(file_name, &_if)가 포함되어 있다. 최종적으로 함수 마지막에 do_iret (&_if) 호출을 통해 유저프로그램이 엔트리 함수에서 시작하게 된다.

load()

위에서 언급한, 실행 파일을 로드하는 함수인 load() 함수를 더 살펴보자면, 전달 받은 file_name을 가지고 해당 파일을 파일시스템 함수를 통해 open 한 후, ELF 파일 포맷에 맞게 로드한다. 페이지 테이블 또한 여기서 생성되고 activate 되고, 이 함수가 반환되고 실행될 do_iret (&_if)을 위해 intr_frame을 설정해 준다.

setup_stack(if_)으로 유저 스택을 준비 (if_의 rsp 멤버를 유저 스택 주소로 저장) 하고, 실행 파일이 가장 처음 실행할 위치인 엔트리 함수를 지정해 준다.(if_의 rip 멤버를 ELF 파일 헤더에 저장된 엔트리 정보 ehdr.e_entry로 저장)

그리고 바로 여기서 우리의 당면 과제인 argument passing을 구현한다. 앞서 인자를 프로세스에게 전달해서 실행하게 된다고 계속 표현했었는데, 이 전달 과정은 곧 유저 스택에 해당 인자를 push 해주는 것과 같다. 이때 push 해주는 포맷은 calling convention을 준수한다. (ABI : Application Binary Interface)

calling convention

1. 유저 프로그램은 call된 함수의 실행에서 인자를 확인 할 때, %rdi, %rsi, %rdx, %rcx, %r8, %r9 를 순서대로 사용한다. (첫번째 인자부터 여섯번째 인자까지. 인자가 더 많다면 스택에 저장해둔다.)

2. caller (해당 프로시저를 호출한 프로시저)는 callee(호출되는 프로시저)가 반환된 다음 수행될 인스트럭션의 주소를 스택에 저장하고, 호출한 프로시저의 첫 인스트럭션의 주소로 jump 한다. x86-64 call 인스트럭션 하나로 이 두가지가 동시에 수행될 수 있다.

3. callee 가 수행된다.

4. callee 가 리턴 값이 있는 프로시저라면, callee 는 %rax 레지스터에 그 값을 저장해 둔다.

5. callee는 아까 2번에서 저장된 되돌아갈 인스트럭션 주소(return address)를 스택에서 꺼내고, 그 인스트럭션 주소로 jump한다. x86-64 ret 인스트럭션으로 수행될 수 있다.

이러한 convention을 가지고 유저 프로그램이 가장 처음 실행될 때는, 첫번째 인자를 전달하는 인자의 개수로 (argc), 두번째 인자를 각 인자들이 저장된 주소값(포인터)가 들어있는 배열의 시작 주소로 (argv) 설정한 후, 엔트리 함수를 실행하게 된다.

상기해야 할 점은 이 인자들이 실제로 저장되는 곳과, 인자들의 주소값 배열이 저장되는 곳 모두가 유저 스택이라는 점이다. 첫번째 그림에서 보이듯, 스택의 높은주소에는 실제 인자가 저장되고, 낮은 주소에는 그 저장된 공간의 주소값이 저장됨을 알 수 있다. (스택은 위에서 아래로 커진다.)

우리가 결국 argument passing을 한다는 것은, 커맨드 라인으로 전달된 인자들을 parsing해서 convention에 맞춰 유저 스택에 저장해 주는 것이다. 이후에 유저 프로그램이 정상적으로 시작될 수 있다.

System Calls

초반에서 언급했듯, 유저 프로그램은 시스템 자원에 맘대로 접근할 수 없다. 커널이 여러개의 유저 프로그램들을 실행하고 있기에, 유저 프로그램은 커널의 지휘에 따라야 한다. 이는 구체적으로 유저 모드와 커널 모드라는 구분을 통해, 유저 모드에서 시스템 자원 접근에 대한 요청을 하고, 커널 모드에서 그 요청을 처리해준 후, 유저 모드로 복귀하는 일련의 과정을 통해 실현된다.
여기서의 요청이 바로 시스템 콜에 해당한다.

가장 먼저 유저 모드와 커널 모드의 구분이 어떻게 이루어지는 지를 살펴보자.

Protection Ring

X86 아키텍쳐의 CPU는 항상 특정한 privilege level에서 동작하도록 설계되었다. 즉, CPU가 동작할 항상 특정 모드를 가지고 동작한다는 이야기이다. 우리가 하던 이야기와 접목해 보면, 커널이 CPU와 연합하여 커널모드, 유저모드의 동작에 대한 제한을 하는 매커니즘이 사용된다는 것이다. 하드웨어의 보조를 받는다고 볼 수 있다.

CPU에는 연산 수행을 위한 많은 instruction이 정의되어 있을 것인데 실행할 수 있는 instruction을 Ring에 따라 제한 시키는 것이다. 예를 들어 100개의 instruction이 있다고 할 때, 거기서 굉장히 조심히 사용되어야할 5개의 instruction이 있다고 한다면 그 5개를 Ring0로 정할 수 있다. Ring0밖에서는 절대 사용되어서는 안될 인스트럭션들이 유저모드와 같은 상황에서 쓰게 되면 큰 문제가 발생할 수 있는데, 그런 상황을 하드웨어적으로 보호하는 것이다.

syscall sysenter instruction을 이용해 특권 검사 없이 Ring 0로 이동할 수 도 있고, iret sysret sysexit등의 instruction을 통해 Ring 3로 이동할 수 있다. int 명령어를 통해서는 단순히 level의 이동이 불가능하고 하나의 검사 과정을 거친 후 level을 이동시킬 수 있다.

어쨌든 이러한 특권은, 현재 프로세스가 가지고 있는 특권을 저장하는 일부 제어 레지스터를 통해 표현될 수 있다. 해당 레지스터에는 모드 비트라는 정보가 set 된다. 핀토스의 코드에서도 코드 곳곳에 해당 레지스터에 모드 비트를 저장하는 부분을 확인할 수 있다.

⬆️ 유저 프로그램을 실행하는 process_exec()함수는, 유저 모드에 해당하는 모드 비트를 intr_frame에 설정해 준다.

⬆️ 커널 스레드를 생성하는 thread_create() 함수에서는, 반대로 커널 모드에 해당하는 모드 비트를 intr_frame에 설정해 준다.

뒤이어 설명하게 될 인터럽트와 시스템 콜에 대한 엔트리 과정에서도 해당 모드 비트를 설정하는 구간이 존재한다(인스트럭션 수행 내부 또는 엔트리 함수 안에 포함되어 있다).

이러한 유저 모드와 커널 모드의 구분을 통해, 커널은 protection 이라는 목적을 달성할 수 있게 된다.

ECF (Exceptional Control Flow)

시스템 콜은 사실 인터럽트의 일종이다. CSAPP의 용어 사용에 따르면 Exception의 일종인 trap에 해당하는 흐름이다. (ECF는 좀더 개념적인 용어라고 이해했다.)

이러한 Exception 또는 갑작스런 흐름의 변화 (ECF)가 왜 필요할까. ECF의 첫 invention은, 응용 프로그램이 무한 루프에 빠졌을 때를 체크하기 위해 운영체제가 일정 간격으로 제어를 넘겨받아 이를 확인하도록 하는 것에서부터 시작했다. 타이머 인터럽트를 통해 이를 구현할 수 있다. 이처럼, 실행되는 프로그램에는 시스템에 대한 변수나 상태 변화가 포함되지 않았다. cpu는 그저 프로그램 카운터를 계속 읽으며 작업을 수행할 뿐이다. 그래서 cpu가 스케줄링에 활용하는 타이머나, 네트워크 패킷의 처리나, 디스크 입출력의 처리 등과 같은 시스템 상태에 대한 반응을 할 수 있는 환경을 만들어 주어야 한다. 이는 Exception이라는, cpu의 작업 흐름에 대한 돌발적인, 예외적인 상황이 발생됨으로써 실현된다. 그리고 이러한 Exception이 발생했을 때, cpu는 미리 등록된 handler 함수를 통해 해당 Exception을 처리(handle)한다.

Exception에는 위와 같이 4가지 종류가 있다.

1. 인터럽트 (Interrupt)
   인터럽트는 cpu 외부의 하드웨어가 발생시킨다. 프로젝트 1에서 다뤘던 timer interrupt가 이에 해당한다. 인터럽트는 비동기(Async)적이다. 특정 인스트럭션을 실행해서 발생한 것이 아니기에, 문맥이 존재하지 않고, 따라서 동기화를 시켜줄 수가 없다. (인터럽트를 처리하는 과정이 중간에 멈출 수 없다는(선점될 수 없다는) 의미이다. 멈출 수 있다는 것은 문맥을 저장하고 이후에 다시 실행하겠다는 것이기 때문이다.)

2. 트랩 (trap) : 시스템 콜 (system call)
   트랩은 의도적인 예외상황이다. 어떤 인스트럭션을 실행한 결과로 발생한다. 따라서 동기화가 가능하다. '의도적인' 이라는 표현에서 알 수 있듯, 트랩은 유저 프로그램이 발생시켜 커널에게 어떤 처리를 요청할 수 있게 한다. ➡ 시스템 콜.

3. 오류 (fault)
   오류는 handler가 정정할 수 있을 가능성이 있는 에러 조건으로부터 발생한다. 만약 handler가 해당 에러 조건을 정정할 수 있다면, 정정한 후 오류를 발생시킨 인스트럭션으로 돌려주어 거기서부터 재실행한다. 예외가 발생한 인스트럭션의 다음 인스트럭션으로 돌아가게 되는 인터럽트와 트랩과 차이점이 존재하는 것이다. 가장 유명한 오류로는 page fault가 있다.

4. 중단 (abort)
   중단은 대개 하드웨어와 같은 복구할 수 없는 치명적인 에러에서 발생한다. 응용 프로그램을 종료함으로써 처리된다.

인터럽트, 예외 등의 용어 사용에 대한 통일된 규정이 없다. 하드웨어에서 발생하는 예외적 흐름과, 소프트웨어에서 발생하는 예외적 흐름을 구분할 수 있으면 된다고 이해했다.
참고로 C++이나 JAVA에서 사용되는 Exception은 다른 레벨에서의 예외사항(응용 수준의 ECF)으로 이해해야 한다.

interrupt

여기서부터는 편의를 위해 모든 Exception을 '인터럽트'로 명명하고, 인터럽트(1번)를 하드웨어 인터럽트로, 2번(트랩) / 3번(오류) / 4번(중단)을 소프트웨어 인터럽트로 표현하려고 한다.

인터럽트는 각각의 특정 경우에 대하여 vector라는 고유 번호를 가진다. 프로세서는 이 vector를 통해서 descriptor table로 접근하여 해당하는 handler를 찾고 그를 실행해 인터럽트를 handle한다.
x86_64 아키텍쳐에서 vector는 0부터 255까지 (0x00 ~ 0xff) 256개가 있다. 따라서 256개의 인터럽트 종류가 있다고 볼 수 있다. 0부터 31까지는 (0x00 ~ 0x1f) 하드웨어적으로 (인텔에서. 아키텍처에서.) 정의된다. (다만 핀토스에서는 이 하드웨어 인터럽트들이 32부터 47까지 (0x20 ~ 0x2f)에 해당된다.) 32부터 255까지는 (0x20 ~ 0xff) 커널 설계자가 정의할 수 있도록 되어 있다.

전통적인 x86 아키텍쳐에서는 시스템 콜이 식별 vector를 가지는 소프트웨어 인터럽트의 일종으로서 정의되었다 (e.g. int 0x80 in linux). x86_64 아키텍쳐에서는 MSR(model specific register)라는 레지스터의 도움을 받아 별도로 처리될 수 있게 되었다. x86_64 아키텍쳐에서는 syscall 이라는 인스트럭션을 통해 소프트웨어 인터럽트의 처리 흐름과 별개로 시스템 콜에 해당하는 예외상황을 발생 시킬 수 있는 것이다. 이를 통해 좀 더 빨리 시스템 콜 handler를 호출할 수 있게 되었다.

interrupt frame

인터럽트는 말그대로 방해, cpu의 작업에 대한 예외적인 상황이다. 다시 말해, cpu가 원래 하던 작업으로 돌아올 수 있어야 한다. 원래 하던 작업은 인터럽트가 발생한 당시의 레지스터의 스냅샷으로 기억될 수 있다. 인터럽트가 발생하면, cpu는 자동적으로 당시의 레지스터 정보들을 커널 스택에 차례로 저장한다.

핀토스에서 이 차례를 반영한, 레지스터 정보를 저장할 수 있는 구조체가 선언되어 있다.
➡️ intr_frame : 인터럽트 프레임.

cpu는 ss 부터 rip 까지에 해당하는 레지스터 정보를 해당 멤버에 저장한다. (스택은 위에서 아래로 커지기 때문에, 위의 구조체의 모양이 거꾸로 스택에 저장된다고 상상하면 된다. 위의 그림에서 Interrupt Stack이라고 명시된 상자 모양을 참고하자.) 그리고 page fault와 같이 error code가 존재하는 인터럽트에 대해서는 cpu가 error_code 에 해당하는 위치까지 스택에 정보를 넣어준다. 이후에 vec_no부터 R멤버 안의 r15까지에 해당하는 레지스터 정보는 인터럽트가 발생하고 인터럽트 handler가 실행되기 이전에 실행되는intrNN_stub(NN은 인터럽트 vector에 해당) 함수와 intr_entry 함수에서 저장해준다.

이렇듯 스택에 intr_frame의 구조에 맞게 정보가 저장되었을 때, 스택 포인터 값을 %rdi에 저장한 후 handler 함수를 실행하면, handler 함수의 첫번째 인자로 intr_frame 구조체의 시작 주소가 전달되는 것과 같은 효과를 낼 수 있다. 결국 handler 함수를 수행하면서 레지스터 정보(인터럽트가 발생한 시점의 레지스터 정보)를 읽을 수 있게 된다.

또한 인자로 받은 intr_frame 구조체에 특정 값을 쓴 후 handler 함수가 반환하게 되면, 그 특정값이 반영된 상태로 원래의 실행 흐름으로 돌아갈 수도 있다. 다시 말해, 레지스터 정보(인터럽트가 발생한 시점의 레지스터 정보)에 쓸 수도 있다. 원리는 아래의 과정을 통해 이해할 수 있다.

인터럽트 handler가 반환된 이후의 intr_entry 인스트럭션을 살펴보면, 인자로 넘겨 주었던 intr_frame 구조체 즉 스택에 저장되어 있는 intr_frame 구조체를 그대로 읽어 그 정보를 각 레지스터에 restore 한다. 단, rip 바로 전 지점 (error_code)까지만 restore 한 후, iret인스트럭션을 실행한다. 그러면 나머지 레지스터 정보들은 cpu가 자동적으로 복구하고 %rip 레지스터에 저장된 주소로 jump하여 원래 하던 작업(인스트럭션)을 수행하게 되는 것이다.

인터럽트가 발생하면 프로세스는 일시적으로 정지한다.

선점(preempt)되다 : 일시적으로 정지되다.
컨텍스트(context) : 커널이 선점(일시 정지)된 프로세스를 다시 시작하기 위해 필요로하는 상태 ➡️ 우리의 경우 intr_frame으로 표현되는 그것.
스케줄(schedule)하다 : 이전에 선점(일시 정지)된 프로세스들 중 다시 실행할 프로세스를 선택하다.

convention

앞서 argument passing 에서 언급한 calling convention과 유사하게 syscall 인스트럭션에 대해서도 convention이 존재한다. 유저가 커널에게 어떠한 처리를 부탁할 때, 처리에 필요한 인자를 전달해야 할 수 있을 것이다. 이때 기본적인 calling convention을 준수하지만, 두가지 다른 점이 있다.

1. %rax에 시스템콜 번호를 저장해 둔다.
   • 인터럽트 vector처럼 시스템 콜에서 각 시스템 콜을 식별하는 식별 번호가 존재한다. 이 번호를 syscall 인스트럭션 실행 전 %rax 레지스터에 저장해 둔다.
2. 4번째 인자는 %r10에 저장해 둔다. 기존의 %rcx가 아니다.
   • 원래의
     %rdi, %rsi, %rdx, %rcx, %r8, %r9 의 순서가 아닌,
     %rdi, %rsi, %rdx, %r10, %r8, %r9 의 순서로 인자가 저장된다.

그리고 시스템 콜에 대한 반환값은 여전히 %rax 레지스터에 저장된다. 시스템 콜이 다 처리되고 유저모드로 전환되면 유저 프로그램은 이 %rax 레지스터의 값을 읽어 시스템 콜에 대한 반환값을 획득한다.

---

각 시스템 콜 (fork, wait, exec)에 대한 구체적인 구현은 시간상, 지면상 문제로 언급하지 않으려 한다. 이번 프로젝트를 통해 인터럽트와 시스템 콜의 처리 루틴을 자세히 볼 수 있었다. 또한 미루고 미뤘던 CSAPP 3장의 어셈블리 인스트럭션들과 친해질 수 있었다.

참고자료

권영진 교수님 OS 강의 자료
CSAPP
https://stackoverflow.com/questions/5223813/how-does-the-kernel-know-if-the-cpu-is-in-user-mode-or-kenel-mode
https://statuesque-cover-3b0.notion.site/Project2-c3dfdeabf57c4ca891906bceca5a3dc3