Exokernel An operating system architecture for application level resource management

ExokernelAn operating system architecture for application level resource management B4.グェン　トアン　ドゥク

全体の内容 • Abstractions in traditional operating systems • Exokernel overview • Exokernel architecture • Exokernel design • Summary

全体の内容 • Abstractions in traditional operating systems • Exokernel overview • Exokernel design • Exokernel implementation • Summary

Abstractions in traditional OS • General purpose abstractions • 固定したインタフェースと実装 • どのアプリケーションがその上で動いているかは考慮しない • 問題点: • Resourceの管理の仕方はほとんど決められ、(applicationは)勝手に変えられない • Hardware abstractionはほとんど変わらない • より良いやり方があっても適用しない

Abstraction in traditional OS • Applicationはそれらの問題点に影響される • アプリケーションのperformanceを減らす • Application特定の性質を利用できない • Applicationに(ハードウェアの)情報を隠す • HW exceptions, page faults, raw device I/O…. • Applicationの機能を限定する • Applicationとhardwareとのインタフェースは唯一に決められる

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間で共有している

Exokernel overview(2) • 保護と管理の分離の理由 • LibOSがprivileged OSと同等な能力を持ち、しかも(applicationの)performanceに影響しない • 各OSが“同居”できるようにする • OSのabstractionの仕方を容易に変化できるようにする

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

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

保護機能と管理機能を分離する • 保護機能に必要な管理機能だけを実現する • Timer, TLBはkernelが管理する • 保護機能とは? • Resourceの所有権を監視する • Resourceが使用される度に所有権をチェックする • 必要なときには、resourceのaccess権利をapplicationから取り戻す • Resourceの使い方はLibOSに任せる

何でも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は色々な情報を持っているので、参加すると最適化できる

何でも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を制御できる

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上で共存できる

Exokernel architecture

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はチェックしなくて済む.

Secure binding(2)

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されなくてもこのコードが実行できる

3.3. Resource multiplexing • Multiplexing CPU • Multiplexing Physical memory • Multiplexing Network • Multiplexing Disk

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を持つ)

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分を譲ることができる

Multiplexing CPU(3) • もしprocessが無理なtime slices数を要求したら、allocate失敗 • CPUがたくさん使いたいprocessは大きなtime slices数を要求する(switching overheadが小さくなる), interactiveなprocessは小さなtime slices数を何回もallocateする(応答性が良くなる) • それでもinteractive processの応答性が良いとは限らない!! • どうするか???

Multiplexing Physical memory • Allocation: • ProcessはTLBWrite(); でphysical pageをもらう • Kernelはpage毎にどのapplicationがアクセス権限やdeallocate権限を持つかを記憶 • Protection • Pageがアクセスされる度に、kernelは権限検査をする • 権限がなければ、accessさせない • Deallocation: • Kernelがその権限を変える。Bindingを開放する。

Multiplexing Network(1) • Application networking: • Application library は全てのnetworking機能(TCP, UDP…)を実現する • Protection: • どのapplicationがこのnetwork messageを所有するか • Exokernel は分からない • そのmessageの意味が分からないからである。 • 解決法: Dynamic package filtering(DPF)

Multiplexing Network(2) Application networking

Dynamic Package Filter(DPF) • LibOS(application)からの小さなfunctionをkernelにdownloadする(code downloading) • そのfunctionは誰がmessageを所有するかを決める • Protection: DPFは特別な言語で書かれ、runtime時にcompileされる。 • PDF言語ではmessageの所有権衝突を容易に検出できる • PDF言語は任意のpriviledged instructionを実行させない

Multiplexing Disks • LibOS(application) がLibFS(file system)を作る • 1つのLibOSが複数LibFSを持っても良い • LibFSがfile systemを作る • LibFSがキャッシュ、disk layout, write order(scheduling)…を制御する • 異なるLibFSが安全に1つのdisk blockを共有できるようにする

Disk protection • Exokernel vs. Microkernel • Microkernel: privileged, 共有できない • Exokernel: non-privileged, 共有できる

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)

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が分からなくても、信頼することができる

Exokernel implementation • 実際にExokernelを実装したシステムがある: • Xok(x86のExokernel), ExOS(LibOS: Unix-like) • Aegis(Exokernel runs on MIPS) • Xok(Exokernel), ExOS: • OpenBSDのlibcを使う • ほとんどのapplicationをOpenBSDからもらう

Xok/ExOSの性能 • FreeBSDのbinaryの実行時間(秒) Xok, OpenBSD, FreeBSDのpax, cp, diff, gcc, gunzip, rm 各々に同じデータを入力する

Global performance: Xok/ExOS vs. BSD • Xok, BSDで同じConcurrent applications setを実行 • Total time to complete a concurrent tasks: system throughput

5. Summary • Exokernel のdesign principlesとarchitectureを調べた. • Exokernelでresourceの保護機能と管理機能を分離することにより、virtual memory, file system, …はapplication levelで作れる • そのため、performanceが良くなる

Exokernel An operating system architecture for application level resource management