1

ExokernelAn operating system architecture for

application level resource management

B4. グェン　トアン　ドゥク

2

全体の内容1. Abstractions in traditional

operating systems2. Exokernel overview3. Exokernel architecture4. Exokernel design5. Summary

3

全体の内容1. Abstractions in traditional

operating systems2. Exokernel overview3. Exokernel design4. Exokernel implementation5. Summary

4

Abstractions in traditional OS General purpose abstractions

固定したインタフェースと実装 どのアプリケーションがその上で動いている

かは考慮しない 問題点 :

Resource の管理の仕方はほとんど決められ、(application は ) 勝手に変えられない

Hardware abstraction はほとんど変わらない

より良いやり方があっても適用しない

5

Abstraction in traditional OS Application はそれらの問題点に影響

される アプリケーションの performance を減らす

Application 特定の性質を利用できない

Application に ( ハードウェアの ) 情報を隠す HW exceptions, page faults, raw device I/O….

Application の機能を限定する Application と hardware とのインタフェースは唯一に

決められる

6

全体の内容

1. Abstractions in traditional operating systems

2. Exokernel overview3. Exokernel design4. Exokernel implementation5. Summary

7

Exokernel overview(1) どのアプリケーションでも resource を自分で管理

できる Resource の管理と保護を分離する

Kernel は安全に resource を保護する Application は効率的に resource を管理する

Kernel は resource を application に export する Virtual memory, file system などは application

library にある それらのライブラリは library operating

system(LibOS) と呼ぶ Hardware は異なる LibOS 間で共有している

8

Exokernel overview(2) 保護と管理の分離の理由

LibOS が privileged OS と同等な能力を持ち、しかも (applicationの )performance に影響しない

各 OS が“同居”できるようにする OS の abstraction の仕方を容易に変化で

きるようにする

9

全体の内容

1. Abstractions in traditional operating systems

2. Exokernel overview3. Exokernel design4. Exokernel implementation5. Summary

10

Exokernel design

3.1. Design principles 3.2. Exokernel architecture 3.3. Resource multiplexing

11

3.1. Design principles 保護機能と管理機能を分離する 何でも Expose する ( 見せる )

12

保護機能と管理機能を分離する 保護機能に必要な管理機能だけを実現する

Timer, TLB は kernel が管理する 保護機能とは ?

Resource の所有権を監視する Resource が使用される度に所有権をチェックす

る 必要なときには、 resource の access 権利を

application から取り戻す Resource の使い方は LibOS に任せる

13

何でも expose する (1) Expose hardware

Application は全ての hardware resource に access できる (CPU, TLB, physical memory, disk, exception, interrupt…)

保護機能を実現できる限り、 resource を低レベルで見せる

Disk block, physical pages… を見せる、高度抽象化したファイルなどとして見せない .

Expose allocation Application allocates resource explicitly 、つま

り、 application は resource allocation 過程に参加する Application は色々な情報を持っているので、参加する

と最適化できる

14

何でも expose する (2) Expose name と system infomation

Physical name を使う (physical disk block…) System 全体の情報を見せる (kernel data

structure, system statistic…) Expose revocation

Visible resource revocation(resource を取り戻すときに、 application に知らせる )

例えば memory を回収するときに、 application がどの page を返すかを決める

Application は所有している resource を制御できる

15

3.2. Exokernel architecture Exokernel はハードウェアの上の薄い layer で

ある。 その layer が hardware を multiplex するし、 export

する (low-level primitives として、 export する ) 例 ): CPU: yeild(), TLB: TLBwrite(), TLBvadelete(),

… Exokernel 上の library operating system が高

度な抽象化を実現する Virtual memory, file system… などを実装する この抽象化は簡単に拡張、変化できる 色々な LibOS が同じ kernel 上で共存できる

16

Exokernel architecture

17

Secure binding(1) Resource を安全に multiplex する ( 複数があるよう

に見せる ) ために、 resource を監視する必要がある Resource の監視を効率的に実現するために、 kernel

は LibOS を resource に secure binding させる Secure binding とは、 application(LibOS) が

resource の所有権をもらうことである Kernel が提供されたプリミティブ群を用いて所有権を宣言す

る ( 例 : TLBwrite()). 宣言するときは bind time と呼び、使用するときは access time と呼ぶ .

Bind time で kernel は権限をチェックする、 access timeはチェックしなくて済む .

18

Secure binding(2)

19

Secure binding(3) Secure binding を実現するために、３つの方

法がある ハードウェアサポートを利用する

TLB fault のとき、 application(LibOS) が TLBWrite() を 呼ぶ (bind time) 、その後、自由に使える (access time)

Software caching Software TLB を実現する

Downloading application code Application code を kernel に download する 権限チェックなどの時にこのコードを kernel で実行 Application が schedule されなくてもこのコードが実行

できる

20

3.3. Resource multiplexing

Multiplexing CPU Multiplexing Physical memory Multiplexing Network Multiplexing Disk

21

Multiplexing CPU(1) CPU を time slices vector として見る Process は CPU の time slices を allocate で

きる ( メモリのように ) Time slice は timer interrupt でマークされる Kernel scheduler はその time slices vector

上の processes を round robin 的に CPU を割り当てる

走っている process に timer interrupt 毎に、kernel が通知する (process が自分の timer interrupt handler を持つ )

22

Multiplexing CPU(2) 走っている process が自分の time slice 数がなく

なっても CPU を返さなければ、超えた time slice数だけを次の round でもらえなくなる 超えた time slice 数には上限がある。その限界を超え

たら kernel は context switching をする (process がtime slice 数の規則を守ったら kernel は context switch しなくても良い )

Process が CPU を返すときに、必要な register だけを保存する ( 例 : FPU state を保存必要のない process はFPU state を保存しなくても良い )

Process が CPU を要らないときには、 yeild(other pid); system call で自分の残っている time slices 分を譲ることができる

23

Multiplexing CPU(3) もし process が無理な time slices 数を要求

したら、 allocate 失敗 CPU がたくさん使いたい process は大きな time

slices 数を要求する (switching overhead が小さくなる ), interactive な process は小さなtime slices 数を何回も allocate する ( 応答性が良くなる )

それでも interactive process の応答性が良いとは限らない !!

どうするか ???

24

Multiplexing Physical memory Allocation:

Process は TLBWrite(); で physical page をもらう Kernel は page 毎にどの application がアクセス権

限や deallocate 権限を持つかを記憶 Protection

Page がアクセスされる度に、 kernel は権限検査をする

権限がなければ、 access させない Deallocation:

Kernel がその権限を変える。 Binding を開放する。

25

Multiplexing Network(1) Application networking:

Application library は全ての networking機能 (TCP, UDP…) を実現する

Protection: どの application がこの network

message を所有するか Exokernel は分からない

その message の意味が分からないからである。 解決法 : Dynamic package filtering(DPF)

26

Multiplexing Network(2)Application networking

27

Dynamic Package Filter(DPF) LibOS(application) からの小さな function を

kernel に download する (code downloading) その function は誰が message を所有するかを決

める Protection: DPF は特別な言語で書かれ、 runtime

時に compile される。 PDF 言語では message の所有権衝突を容易に検出できる PDF 言語は任意の priviledged instruction を実行させない

28

Multiplexing Disks LibOS(application) が

LibFS(file system) を作る 1 つの LibOS が複数 LibFS を持っ

ても良い LibFS が file system を作る LibFS がキャッシュ、 disk

layout, write order(scheduling)… を制御する

異なる LibFS が安全に 1 つのdisk block を共有できるようにする

29

Disk protection Exokernel vs. Microkernel

Microkernel: privileged, 共有できない Exokernel: non-privileged, 共有できる

30

Disk protection Block level protection

複数の file system(FS) に disk を multiplex する必要があるからである

異なる FS が 1 つの block を共有できる 難しい問題 :

誰がこの disk block を使用できる ? FS が所有している disk block を記憶しているはずの

で、 kernel も記憶すると無駄 FS の metadata(file system の情報 ) を再利用したい . しかし、 kernel はその metadata の format や意味が分か

らない 解決法 : Untrusted Deterministic Functions(UDF)

31

Untrusted Deterministic Functions(UDF) LibFS は metadata type 毎に interpreter function “owns” を提供

Owns(metadata) = set of blocks controled by metadata Correctness:

Owns は決定的でなければならない ( つまり、 Owns は同じ入力で常に同じ出力を出す )

Own 集合が変わる度に Inductive testing をする UDF の使い方 :

Proc Initialize(medatada)If( owns(metadata) != {} ) then error();

Proc Allocate(metadata, b){old_set = owns(metadata);<let LibFS changes metadata>new_set = owns(metadata);if( new_set != old_set U {b}) then error();

} Deallocate は Allocate と同様

Kernel は metadata が分からなくても、信頼することができる

32

全体の内容

1. Abstractions in traditional operating systems

2. Exokernel overview3. Exokernel design4. Exokernel implementation5. Summary

33

Exokernel implementation 実際に Exokernel を実装したシステム

がある : Xok(x86 の Exokernel), ExOS(LibOS:

Unix-like) Aegis(Exokernel runs on MIPS)

Xok(Exokernel), ExOS: OpenBSD の libc を使う ほとんどの application を OpenBSD か

らもらう

34

Xok/ExOS の性能 FreeBSD の binary の実行時間 ( 秒 )

Xok, OpenBSD, FreeBSD のpax, cp, diff, gcc, gunzip, rm 各々に同じデータを入力する

35

Global performance: Xok/ExOS vs. BSD

Xok, BSD で同じ Concurrent applications set を実行 Total time to complete a concurrent tasks: system throughput

36

5. Summary Exokernel の design principles と

architecture を調べた . Exokernel で resource の保護機能と

管理機能を分離することにより、 virtual memory, file system, …は application level で作れる

そのため、 performance が良くなる