Advanced Operating Systems Structure(3): Exokernel

개요

이전 포스트에서는 SPIN kernel에 대해서 알아봤다. 이번에는 SPIN과 다른 방법으로 확장성에 대해 접근하는 Exokernel이라는 커널에 대해서 알아보자. Exokernel은 하드웨어를 extension(Library OS)에 직접적으로 노출시켜서 사용하게 한다. 대신 자원을 사용하기 전에 인증 절차를 거쳐서 자원을 보호한다.

인증과 사용의 분리

Exokernel은 Library OS들이 자원에 대해 요청하면 Library OS과 하드웨어를 바인딩하고 자원에 접근할 수 있는 key를 준다. 다른 말로 Exokernel은 하드웨어를 안전한 바인딩을 통해서 노출시키고 Library OS들은 암호화된 키를 가지고 하드웨어에 직접 접근할 수 있다. 그래서 키를 변조하거나 다른 Library OS에게 전달할 수 없다. 만약 다른 Library OS에서 다른 Library OS에서 발급받은 key를 이용해서 접근하려고 하면 유효한 key더라도 Exokernel을 자원 접근을 거부한다.

secure binding을 만드는 것은 꽤 비용이 많이 드는 작업이다. 특정 Library OS이 특정 하드웨어를 접근할 때 자원을 제공할 수 있는지 확인하고, 인증 key를 만들어줘야 하기 때문이다. 하지만 한 번 key를 생성한 후 Library OS과 바인딩시킨 후에는 Exokernel이 자원 관리에 관여하지 않기 때문에 Library OS이 하드웨어를 사용하는 비용은 줄어든다.

이렇게 하면 매번 자원을 사용할 때 마다 인증 절차를 거쳐야 하는데 성능에 문제가 없는지 걱정이 된다. 하지만 하드웨어 자원의 의미를 생각해보면 그렇지 않다는 것을 알 수 있다. 몇 가지 예를 들어보자.

TLB entry

TLB의 경우 memory management system은 프로세스들에게 메모리를 virtual memory 형태로 제공해준다. 그래서 memory management system의 경우 커널에게 한 번의 TLB entry만 요청하고, 프로세스들에게는 virtual memory 형태로 제공해줌으로써 여러 번의 요청 없이 한 번 할당받은 자원을 가지고 Virtual to Physical 맵핑 정책을 통해서 관리하면 된다.

Packet Filter

Packet filter도 비슷하다. 패킷을 예측하는 것은 kernel 입장에서는 비용이 많이 드는 작업이다. 하지만 packet filter를 커널에 설치하고, 들어오는 패킷을 커널에 설치된 로직을 통해서 처리하게 되면 설치할 때는 비용이 많이 들지만 한 번 설치되면 border crossing 비용 없이 처리할 수 있게 되어서 효율적이다.

Secure binding을 만드는 법

위에서 언급했던 secure binding 만드는 방법에서는 3가지 방법이 있다.

• hardware mechanisms: TLB entry 같이 하드웨어에서 제공하는 영역을 Library OS에서 할당받아서 page frame 등으로 나눠서 접근한다.
• software caching: 하드웨어 TLB를 효율적으로 사용하기 위해서 각 Library OS들은 하드웨어 TLB와 맵핑되는 소프트웨어 TLB(S-TLB)를 관리한다.
• downloading code: 수행할 코드를 커널에 직접 삽입하는 방법을 사용해서 border crossing을 회피할 수 있게 한다. SPIN의 Logical Protection Domain과 비슷하게 동작한다. 하지만 SPIN은 언어적으로 강제되는 부분이 있지만 Exokernel은 그렇지 않아서 조금 더 보안적인 방법이다.

직접적으로 하드웨어 자원에 접근하게 하고, 코드를 커널에 삽입하는 방법이 어떻게 안전하냐라고 할 수 있지만 하드웨어를 요청하는 Library OS들이 아무렇게나 접근할 수 있는 게 아닌 신뢰할 수 있는 사용자에 한해서만 접근이 가능하게 했다.

Default Core Service

SPIN과 같이 Exokernel의 Default Core Service들에서도 알아보자.

Memory Management

memory management system에서 page fault 발생 시 어떻게 처리되는지 알아보자. 프로세스가 실행 중인 상태에서 평소에는 메모리 접근할 때는 문제가 없다. 그러다 page fault가 나게 되면 먼저 커널에게 전달된다. 커널은 어떤 Library OS이 현재 CPU에서 실행되는지 알기 때문에 해당 Library OS이 등록한 핸들러를 수행시킨다.

memory management system은 현재 page fault가 발생한 physical frame에 대해서 커널에 새 page frame을 요청해서 현재 존재하는 virtual to physical mapping 정보를 유지하려고 한다. 이 경우에 다시 바인딩 절차를 가진다.

Software TLB

Exokernel은 context switching 시 TLB에 대해 들어가는 오버헤드(eg. page fault)를 완화하기 위해 S-TLB를 도입한다. context switch가 일어나게 되면 대부분의 TLB entry에서 page fault가 발생하기 때문에 Exokernel에 각 Library OS마다 S-TLB를 만들고 context switch시에 S-TLB를 TLB에 로드해서 page fault가 자주 안 일어나게 막는다.

CPU scheduling

CPU scheduling은 일반적으로 사용하는 시분할 방식으로 스케줄 된다. time quantum으로 나눠진 time slot들이 존재하고 각 Library OS들은 번갈아 가면서 time quantum 동안 수행되고, context switch를 한다.

자원 회수

Exokernel을 각 Library OS에게 할당했던 자원을 다른 Library OS에게 할당하기 위해서 등 회수할 필요가 있다.

Exokernel Data Structure

정리하며 Exokernel Data Structure는 이런 식으로 구성되어있다. 각 Library OS는 여러 하드웨어를 다루는 여러 시스템들을 가지고 있고, Exokernel과 바인딩되어서 동작한다.

각 OS들은 tiem slice 되어 time quantum만큼 동시에 수행된다. 수행 중 exception, interrupt, system call, memory remap 등 이벤트가 발생할 때 각 Library OS마다 handler entry point들을 가지고 있다. 또한 context switch가 발생했을 때, TLB의 page fault를 완화시키기 위한 S-TLB도 가지고 있다. 이러한 프로세서 동작 중에 필요한 정보를 Exokernel은 PE(Processor Environment)라는 Data Structure로 관리한다.