第二课：ExoKernel

操作系统课程通常会介绍微内核（MicroKernel）的概念，并与宏内核（MacroKernel）进行对比。本节课我们会介绍另一种内核的架构，即MIT的Frans Kaashoek教授提出的ExoKernel。

上课笔记（by 14级 糜泽羽）

  1. 虽说两者都是简化了内核，但Mircokernel更多强调的是isolation和robustness，Exokernel强调的是定制性。
  2. 任何问题都可以通过加抽象层解决，性能问题都可以通过减抽象层解决
  3. Xok是在x86平台实现的Exokernel
  4. LibOS增加了一种可能，让对系统比较熟悉的人能够更好的使用硬件。但对大多数人来说，写一个自己的LibOS毕竟太难，这也正是Exokernel没有大规模推广的原因。Xen这样的系统在设计的时候就考虑到了透明性，所以它对业界产生了很大的影响。

  5. Exokernel的3个技术

    • 所有的access control都是uniform的，这点体现在了磁盘和内存的控制上。
    • 把hardware与软件abstraction绑定，比如把disk buffer与physical memory绑定
    • downloaded code
      • 把用户态的代码download到内核态运行
      • files may require valid updates to their validation times

  6. Protected Sharing Mechanism

    • Software regions
      • 这块地址是特殊的地方，不是一般的内存
      • 由exokernel读写，对外必须通过system call访问

  7. Storage Basic In Linux

    • Unix V6的naming layer
      • block layer
      • file layer
        • 把block组合成file
      • inode number layer
        • inode是metadata，是一个具有很多指针的结构，保存了数据的block number。其中有direct block，还有indirect block 列表
      • file name layer
        • 把inode与file name绑定在一起
      • path name layer
        • 把文件组织成树状结构
      • absolute path name layer
        • 提供根目录
      • symbolic link layer
    • 一般的file system实现
      • 给用户提供一个VFS接口，包括open，close，read，write，fsync等
        • 不同的文件系统对这些接口有不同的实现，但必须提供实现。
      • VFS下面是具体每个文件系统的实现，再下面是buffer cache层。最下面一层是block layer，在这一层里面有block driver，由它将数据写入disk，或者有一个io scheduler，由它决定写入哪里。

  8. XN+LIBFS

    • XN是storage system，本质上提供一个block layer的系统；LIBFS是上层的文件系统，实现inode这些抽象，可以实现ext2，FAT32系统
    • 每一个libOS可以有多个LIBFS
    • 为了实现isolation
      • 创建新的文件格式不需要特殊权限。
        • 在早先的linux中无法做到，装新文件系统必须装module
      • 在raw dis block level 分享blocks
      • 实现cache
    • Access Control
      • 谁能使用一个block？这是XN解决的问题
      • libFS去做access control，但是必须使用XN来帮忙，这就必须使用download code来帮忙。
      • 很多时候，XN不知道文件格式，是无法做保护的。假如一个libOS拥有一个inode，他拥有这个inode指向的所有的blocks，但是问题是，XN如何知道这是一个inode，如何找到这些block？XN必须需要一个代码，帮助他验证block的归属权限，这个代码由libOS提供，exokernel将其download到kernel中执行。
      • 总的来说，UDF在linux中也是常常使用的概念。这段代码不是随便写的
        • 第一，它不是由通用的语言写的，而是由restricted的语言来写，只为了完成限定的功能。
        • 第二，这个编译过程必须由XN完成，XN可以在这个过程检查，编译完之后，下次在使用UDF就不检查了。（Linux 中有一个BPF的概念，它的核心在于LInux kernel收到一个网络包，它有很多网卡，就可以转发，但转发需要规则，规则不可能写死，可以动态配置，这些配置就由用户提供。整个原理与downloaded code类似）
      • 多个libOS共享一块磁盘，如何保证isolation？
        • in-kernel cache registry
          • 提供在disk和memory之间做一个映射，把一块memory映射到磁盘的block中，与memory map类似。
          • 每一个application访问磁盘，不能直接操作磁盘，而是由Exokernel控制。LibOS通过cache registry把内存映射到block中，然后只能通过访问内存的方式访问block。exokernel会修改页表，将某个页面设置为不可读不可写，当libOS读写的时候，exokernel去load block。exokernel可以在映射的建立过程实现控制，之后再也不控制
      • UDF
        • deterministic意味着，只要输入是一样的，输出一定是一样的。本质上用RISC汇编代码来写，所以编译成汇编代码也很容易。
        • Template
          • 每一个磁盘type，都有一个template。
          • 每一个template都有3个函数
            • owns-udf
              • 对于每一个metadata，这个函数会返回这个metadata指向的block
              • exokernel用这个函数来判断某个libOS是否拥有block的控制权。
              • 当一个libOS说，要分配一个新的block，加到metadata中。XN首先运行owns，得到metadata的block列表，保存起来，然后将block给metadata中，将结果与之前的比较，看是否分配了正确的block。
                • 在这个过程中，可以检查access权限，或者判断block是否tainted
            • acl-uf
              • 用来判断是否对某个metadata有修改权限。
              • 当libOS要对metadata做改动，他请求XN做修改。XN收到请求之后，先运行acl-uf去判断是否有权限修改。
            • size-uf
              • 得到metadata拥有的size
    • Atomic Metadata Update
      • inode中存着size的值。当我要增加一个block，包含2个步骤
        • 在inode中添加一个新的映射，指向这个block（这步先做，假如这步crash，size没有增加，用户不会出错，如果颠倒，用户就会访问没分配的数据）
        • 把inode中的size增加
    • Ordered Disk Writes
      • 有3个重要原则
        • 在清除指向磁盘的pointer之前，不要重新使用这个block
        • 如果pointer指向的数据没有被初始化，永远不要创建persistent pointer指向他。否则指向它之后，发生crash，用户会读到没有初始化的数据
        • 移动磁盘数据的时候，永远记得先set new pointer，再去reset old pointer。否则旧的没了，新的还没有赋值。
      • 要保证这些原则，意味着有很多的sync。因为很多操作是并行的，为了保证这些操作的顺序性，必须强制性的sync。
        • sync操作很慢，不能忍
      • 如何实现呢？
        • 对于第一个原则，使用reference count解决
        • 使用taint block（这个技术十分有用，会用来保护用户隐私。加入用户在一个内存中写了信用卡号，这个内存被染色，内存的染色可以通过拷贝传递。当这个被染色的内存要被通过网络发送出去的时候，就会去检查。）
          • 假如一个磁盘没有初始化，就把他设为taint，此时如果有一个block指向这个taint block，那么这个block也是taint。
          • XN规定，taint的block不能写到磁盘上，除非应用程序主动做初始化操作。
          • 这样就可以并行操作了。
    • XN的使用方法
      • Startup
        • libFS告诉XN，把我上次注册的root load到buffer cache中
      • read
        • libFS要读某个block。它先在registry中创建一个entry，data和metadata同时发给XN。
        • XN使用owns-udf去检查，metadata和data是否被root指向。
        • LibFS初始化一个read操作，XN使用acl-uf检查metadata block，看看有没有读的权限。
      • raw read support
        • 为了提升性能。我可以提前把用户的东西laod进来
        • 如果用户要读一个磁盘，但是你不能访问，如果你要访问，必须做刚才read的操作。
      • Allocate
        • XN提供block free list 给libFS
        • libFS向XN申请，要求allocate一个block，同时传入metadata，free block，对metadata的修改
        • XN首先检查block是否free，如果不是free，就拒绝
        • XN运行acl-uf，看看是否有权限修改metadata
        • XN运行owns-udf判断是否正确修改了。
      • Write
        • libFS传入要修改的block
        • XN首先检查block是不是taint，是否能从root得到，如果不行就拒绝
        • 如果这次修改改变了某些block的taint状态，在这里需要修改taint list。

ExoKernel论文阅读笔记

课后阅读论文为：Application Performance and Flexibility on Exokernel Systems。以下选择了一些同学的论文阅读笔记。

陈聪聪（软件学院14级研究生，1140379062）

Q1: Application can gain a better performance of memory and file system in Exokernel compared with microkernel or monolithic kernel, why? And what's the price of performance profit?

在传统的操作系统中，只有拥有特权的服务器和内核才能管理系统的资源。不受信任的应用只能使用特定的接口和实现。而这种组织方式是非常不好的，接口为了能适应这些应用必须要满足各种各样的需求，还需要考虑接口可能被用到的各种情形，这都使得应用开发不够灵活并且错误的成本很高。 应用程序比操作系统更了解它们对资源的需求，因此exokernel通过赋予应用程序对资源更多的控制权解决了上述问题。Exokernels将保护机制从管理中分离出来：保护资源但是却将资源的管理权委托给应用程序另外exokernel制定了如下的原则，这都使得应用程序在内存和文件系统的处理上有更好的性能。

  1. 开放分配功能：exokernel允许LibOS请求特定的物理资源，比如如果libos能够请求特定的物理页表，就能减少工作集中的页表的缓存冲突。甚至资源不能偷偷地被分配，libos能够参与到每一个分配决策中。
  2. 开放命名：exokernel能够使用物理名称。物理名称更加的高效，因为这中间省略了虚拟名称与物理名称之间的转换。
  3. 开放撤销功能：应用程序可以选择放弃使用某些资源，每个应用程序都对它们的物理资源集有着控制权。
  4. 开放信息：exokernel开放所有的系统信息和收集到的数据，这些信息对于应用程序来说可能不是那么容易获得。

缺点是：这种内核会产生很多额外的上下文切换，这是很昂贵的代价。两个应用程序之间的通信变得复杂，效率变慢。另外，在用户级服务器中，功能分区很复杂。

Q2: Exokernel grants the applications more control over hardware resource. How does Exokernel protect application/libos against each other? Please consider CPU, memory and storage. And how to understand this goal of paper: to separate protection from management?

  1. exokernel给应用程序分配物理内存页面，并且控制TLB。一个应用程序可以向另外一个应用程序发送一个空间来共享某一页面。
  2. exokernel按照物理块地址给应用程序标记物理内存，允许应用程序自行优化内存。当应用程序初始化要使用的磁盘时，它给内核提供了一个可以决定应用程序要控制哪个磁盘快的功能。内核使用回调来验证，当分配一个新块时，除了已经控制的块外，只分配了这一块。
  3. 提供软件抽象将硬件资源绑定在一起。应用程序可以访问控制物理页表和I/O磁盘，同时也可以安全的使用相互之间的缓存页表。保护机制保证一个进程只能获取一个缓存页表，如果它还有获得相应的磁盘快的权限。
  4. 有些软件抽象是允许应用程序下载代码的，这要求这些抽象的保护没有映射到硬件抽象。
  5. 对所有的资源执行相同的访问控制。 这些exokernel软件抽象的关键是它们既不阻碍对硬件资源的低级别访问，也不过度的限制所能实现的抽象保护。

对于本论文所要实现的将保护机制和管理分离，我认为就是给应用程序提供尽可能低级别的访问接口，最为理想化的是硬件接口。例如exokernel应该保护帧缓存而不需要理解视窗系统，要保护磁盘而不需要理解文件系统。

Q3: Open question - do you think why has not Exokernel been as popular as monolithic kernel (Linux) and Hybrid kernel (Windows NT)?

我个人认为虽然exokernel对应用程序放开访问硬件资源的权限，但是并不是所有的程序员能够熟练的掌握软、硬件的知识，在实际的开发过程中，并不像使用软件接口那样方便，所以导致在exokernel系统上没有像其他主流操作系统上那么多应用，甚至连一个高效的符合人机关系的用户桌面都没有，导致很差的用户体验，因此推广就显得更加的艰难。

杨成（软件学院14级研究生，1140379020）

Q1: Application can gain a better performance of memory and file system in Exokernel compared with microkernel or monolithic kernel, why? And what's the price of performance profit?

  1. In traditional OS (microkernel or monolithic kernel), only privileged servers and the kernel can manage system resources. Untrusted applications are restricted to the interfaces and implementations of this privileged software. Because application demands vary widely, an interface designed to accommodate every application must anticipate all possible needs. The implementation of such an interface would need to resolve all tradeoffs and anticipate allways the interface could be used. The exokernel architecture solves this problem by giving untrusted applications as much control over resources as possible. It does so by dividing responsibilities differently from the way conventional systems do. Exokernels separate protection from management: they protect resources but delegate management to applications. The exokernel protects pages and disk blocks, but applications manage them.
  2. Exokernels provide primitives at the lowest possible level required for protection—ideally, at the level of hardware (disk blocks, context identifiers, TLB, etc.). Resource management is restricted restricted to functions necessary for protection: allocation, revocation, sharing, and the tracking of ownership.

Q2: Exokernel grants the applications more control over hardware resource. How does Exokernel protect application/libos against each other? Please consider CPU, memory and storage. And how to understand this goal of paper: to separate protection from management?

  1. The CPU is multiplexed by dividing time into round-robin-scheduled slices with explicit notification of the beginning and the end of a time slice. The areas of memory in exokernels can only be read or written through system calls. Exokernels’ protection mechanism guarantees that a process can only access a cache page if it has the same level of access to the corresponding disk block. At the same time, TLB is under Exokernels’ control to make sure that applications only use their own memory page. As for storage, exokernels use secure bindings to move access checks to bind time rather than checking at every access. And, exokernels use the UDF mechanism to protect disk blocks using the libFS’s own metadata. Meanwhile, metadata that is persistent across crashes cannot be written when it contains pointers to uninitialized metadata, and that reallocation of a freed block must be delayed until all persistent pointers to it have been removed.
  2. “To separate protection from management”, means two parts of definition: First, the exokernel architecture gives untrusted applications as much control over resources as possible, it delegate management to applications. Resource management is restricted to functions necessary for protection: allocation, revocation, sharing, and the tracking of ownership. Second, Exokernels provide primitives at the lowest possible level required for protection—ideally, at the level of hardware (disk blocks, context identifiers, TLB, etc.).

Q3: Open question - do you think why has not Exokernel been as popular as monolithic kernel (Linux) and Hybrid kernel (Windows NT)?

  1. Difficult interface design. The goal of an exokernel system is for privileged software to export interfaces that let unprivileged applications manage their own resources. At the same time, these interfaces must offer rich enough protection that libOSes can assure themselves of invariants on high-level abstractions. It generally takes several iterations to obtain a satisfactory interface, as the designer struggles to increase power and remove unnecessary functionality while still providing the necessary level of protection.
  2. Code Messes. The ease of creation and mixing of libOSes could lead to code messes that would be a nightmare for maintenance coders and system administrators. Maintenance coders would have to deal with not only the application code, but any overriden abstractions or new implementations. Information loss. Information that could otherwise be useful to a kernel can be lost if the related abstractions are implemented in libOSes rather than the kernel. For instance, if virtual memory and the file system are completely at application level, the exokernel may be unable to distinguish pages used to cache disk blocks and pages used for virtual memory.
  3. Self-paging libOSes. Self-paging is difficult, and self-paging libOSes are even more difficult because paging can be caused by external entities (e.g., the kernel touching a paged-out buffer that a libOS provided). Careful planning is necessary to ensure that libOSes can quickly select and return a page to the exokernel, and that there is a facility to swap in processes without knowledge of their internals.

References

  1. Application Performance and Flexibility on Exokernel Systems, SOSP’97
  2. Exokernel - OSDev Wiki: http://wiki.osdev.org/Exokernel

王臻（软件学院14级研究生，1140379082）

Q1: Application can gain a better performance of memory and file system in Exokernel compared with microkernel or monolithic kernel, why? And what's the price of performance profit?

Why better performance:

In traditional kernels, only privileged servers and the kernel can manage system resources and they present hierarchical abstractions. Applications in user mode have to use system resources through interfaces provided by servers or kernels(e.g system calls). This mechanism brings a bottleneck caused by system calls overhead.

Compared with traditional kernel, Exokernel gives untrusted/trusted applications as much control over resources as possible. So, applications decided how to use or manage the resources which is allocated to them. Since applications can manage resources itself in its own way(not through system calls), there's no bottlenecks anymore.

It's interesting that exokernel provides as less abstractions as possible and lets applications implement abstractions itself.

The price:

  1. It will be very complex for programmers to implement such applications which have to manage systems resources(e.g. libOSes to provide high-level abstractions).
  2. Exokernel interface design is not simple. The interfaces must let applications have more powerful control on their own resources. At the same time the interfaces must offer enough protection that libOSes can assure themselves of invariants on high-level abstractions.
  3. Information loss. Valuable information can be lost by implementing OS abstractions at application level.
  4. Since applications including libOSes have to manage system resources or provide high-level abstractions, it will be very difficult for them to page themselves.

Q2: Exokernel grants the applications more control over hardware resource. How does Exokernel protect application/libos against each other? Please consider CPU, memory and storage. And how to understand this goal of paper: to separate protection from management?

Part I: Questions

How does Exokernel protect applications/libOSes against each other: Of course, exokernel must be able to provide UNIX-like protection, including access control on high-level objects where required for security. Exokernel meets the needs using 3 design techniques to support for protected abstractions:

  1. secure binding. A secure binding is a protection mechanism that decouples au thorization from the actual use of a resource. Protection checks involved in enforcing a secure binding can be implemented by kernel or hardware quickly and a secure bind performs authorization only at bind time. A secure bind allows the kernel to protect the resources without understanding the sematics(the work about sematics should be done by user-level applications).
  2. visible revocation. Once resources have been bound to applications, there must be a way to reclaim them and break their secure bindings. An exokernel uses visible revocation for most resources. Even the processor is explicitly revoked at the end of a time slice; a library operating system can react by saving only the required processor state. When a revocation occurs, a application can use its own way to restore its state according to the information of visible revocation.
  3. abort protocol. An exokernel must also be able to take resources from libOSes/applications that fail to respond satisfactorily to revocation requests. For uncooperative libOSes/Applications, an exokernel uses force to reclaim resources back. Usually an exokernel breaks all existing secure bindings and inform the libOSes when this satuation happens.

To separate protection from management:

Compared with traditional kernel, Exokernel gives untrusted/trusted applications as much control over resources as possible. The kernel is just responsible for resource protection and resource management which is restricted to functions necessary for protection: allocation, revocation, sharing, and the tracking of ownership. So, applications decided how to use or manage the resources which is allocated to them and the kernel doesn't care about it.

Q3: Open question - do you think why has not Exokernel been as popular as monolithic kernel (Linux) and Hybrid kernel (Windows NT)?

In my opinion, there are some reasons:

  1. Exokernel interface design is not simple. The author mentioned that it generally takes several iterations to obtain a proper interface and most of their major exokernel interfaces have gone through multiple designs over several years.
  2. It's too complex for ordinary programmers to design and implement applications/libOSes to run on exokernels! You have to get a whole picture of resources model and system abstractions and understand them. Then your applications will be responsible for manage all resources. This brings too much burden for programmers.
  3. Both exokernels and libOSes are architecture-dependent. The portablity of such applications will sucks!
  4. Any change within the same architectures or hardware will leads to changes of exokernels and applications/libOSes.

Part II: How I read this paper:

Problems: Since monolithic kernels and microkernels both suffer a bottleneck in application performance, people want to design new kernels to solve this problem. The exokernel is brought up to solve it. The authors want to show that the perfoemance and flexibility on exokernel systems is better than or comparably with traditional operating systems. So, it could be a really practical sulotion.

Related work: The exokernel has been propose. It provided evidence that the exokernel approach was promising but left many questions unanswered. Previous approaches to extensibility like better microkernels, virtual machines, and downloading untrusted code into the kernel all suffer some problems.

Observations:

  • The exokernel approach raises several questions:
  • Can ambitious applications actually achieve significant performance improments on exokernel?
  • Will traditional applications pay a price in reduced performance?
  • Is global performance compromised when no centralized authority decides scheduling and multiplexing policies?
  • Does the lack of a centralized management policy for shared OS structrues lower the integrity of the systems?
  • If our solution answers those questions which is about performance well, the exokernel approach may be accepted by people in a large scale.

Solutions: The authors implement a exokernel system which's named Xok/ExOS. Xok is the exokernel for Intel x86-based computers and ExOS is the default libOS. it overviews the Xok/ExOS system.

Evaluation: The results show that common unmodified UNIX applications can enjoy the benefits of exokernels: applications either perform comparably on Xok/ExOS and the BSD UNIXes, or perform significantly better(Section 6). In addition, the results show that customized applications for exokernels can benefit substantially from control over their resources(Section 7). Morever, the global performance is not compromised(Section 8). The Xok/ExOS's architecture also solved the system integrity problem.

Comments: It's a novel thought! Although this design still has some major defects(see in Answer to question 3), it may be very useful in some special areas which demand high performance of applications.

袁博（软件学院14级研究生，1140379089）

Q1: Application can gain a better performance of memory and file system in Exokernel compared with microkernel or monolithic kernel, why? And what's the price of performance profit?

Fisrt question:

The principal goal of an exokernel—giving applications control—is orthogonal to the question of monolithic versus microkernel organization. If applications are restricted to inadequate interfaces, it makes little difference whether the implementations reside in the kernel or privileged user level servers ; in both cases applications lack control. For example, it is difficult to change the buffer management policy of a shared file server. In many ways, servers can be viewed as fixed kernel subsystems that happen to run in user space. Whether monolithic or microkernel based, the goal of an exokernel system remains for privileged software to provide interfaces that do not limit the ability of unprivileged applications to manage their own resources.

This microkernel organization would cost many additional context switches; these are particularly expensive on the Intel Pentium Pro processors on which Xok runs. Furthermore, partitioning functionality in user level servers tends to be more complex. It is said that microkernel and monolithic kernel provide the abstraction of hardware, and high-level abstraction can’t get the best performance. The exokernel architecture solves this problem by giving untrusted applications as much control over resources as possible. they protect resources but delegate management to applications. library implementations are unprivileged and can therefore be modified or replaced at will. We refer to these unprivileged libraries as library operating systems, or libOSes. The goal of an exokernel is to give efficient control of resources to untrusted applications in a secure, multiuser system.

Some newer microkernels push the kernel interface closer to the hardware, obtaining better performance and robustness than previous microkernels and allowing for a greater degree of flexibility, since shared monolithic servers can be broken into several servers. Techniques to reduce the cost of shared servers by improving IPC performance, moving code from servers into libraries, mapping read only shared data structures, and batching system calls can also be successfully applied in an exokernel system.

Libraries are simpler than kernels. The “edit, compile, debug” cycle of applications is considerably faster than the “edit, compile, reboot, debug” cycle of kernels. A practical benefit of placing OS functionality in libraries is that the “reboot” is replaced by “relink.” Accumulated over many iterations, this replacement reduces development time substantially. Additionally, the fact that the library is isolated from the rest of the system allows easy debugging of basic abstractions. Untrusted user level servers in microkernel based systems also have this benefit. The conclusion is listed as follow. Exokernel don’t provide abstraction to the applications. Exokernel makes applications use and manage their resources more by using the libOS which is simpler than kernel. The applications “know” about the resource better (like memory and file system), so they can focus on Improving efficiency of resource use to improve performance. Exokernel will focus on resource isolation and multiplexing and protected share.

Second question:

Exokernels are not a panacea. This subsection lists some of the costs we have encountered.

Exokernel interface design is not simple. The goal of an exokernel system is for privileged software to export interfaces that let unprivileged applications manage their own resources. At the same time, these interfaces must offer rich enough protection that libOSes can assure themselves of invariants on high level abstractions. It generally takes several iterations to obtain a satisfactory interface, as the designer struggles to increase power and remove unnecessary functionality while still providing the necessary level of protection. Most of our major exokernel interfaces have gone through multiple designs over several years.

Information loss. Valuable information can be lost by implementing OS abstractions at application level. For instance, if virtual memory and the file system are completely at application level, the exokernel may be unable to distinguish pages used to cache disk blocks and pages used for virtual memory. Glaze, the Fugu exokernel, has the additional complication that it cannot distinguish such uses from the physical pages used for buffering messages. Frequently used information can often be derived with little effort. For example, if page tables are managed by the application, the exokernel can approximate LRU page ordering by tracking the insertion of translations into the TLB. However, at the very least, this inference requires thought.

Self-paging libOSes. Self paging is difficult (only a few commercial operating systems page their kernel). Self-paging libOSes are even more difficult because paging can be caused by external entities (e.g., the kernel touching a paged out buffer that a libOS provided). Careful planning is necessary to ensure that libOSes can quickly select and return a page to the exokernel, and that there is a facility to swap in processes without knowledge of their internals (otherwise virtual memory customization will be infeasible).

Q2: Exokernel grants the applications more control over hardware resource. How does Exokernel protect application/libos against each other? Please consider CPU, memory and storage. And how to understand this goal of paper: to separate protection from management?

First Question:

In separating protection from management, an exokemel performs three important tasks: (1) tracking ownership of resources, (2) ensuring protection by guarding all resource usage or binding points, and (3) revoking access to resources. To achieve these tasks, an exokemel employs three techniques. First, using secure bindings, library operating systems can securely bind to machine resources. Second, visible revocation allows library operating systems to participate in a resource revocation protocol. Third, an abort protocol is used by an exokemel to break secure bindings of uncooperative library operating systems by force.

Secure Bindings. One of the primary tasks of an exokemel is to multiplex resources securely, providing protection for mutually distrustful applications. To implement protection an exokernel must guard each resource. To perform this task efficiently an exokemel allows library operating systems to bind to resources using secure bindings, We use three basic techniques to implement secure bindings: hardware mechanisms, software caching, and downloading application code.(ex: software TLB)

Visible Resource Revocation. Once resources have been bound to applications, there must be a way to reclaim them and break their secure bindings. Revocation can either be visible or invisible to applications. Traditionally, operating systems have performed revocation invisibly, deal locating resources without application involvement. For example, with the exception of some external pagers [2, 43], most operating systems deal locate (and allocate) physical memory without informing applications. This form of revocation has lower latency than visible revocation since it requires no application involvement. Its disadvantages are that library operating systems cannot guide deal location and have no knowledge that resources are scarce. The use of physical resource names requires that an exokemel reveal each revocation to the relevant library operating system so that it can relocate its physical names. For instance, a library operating system that relinquishes physical page “5” should update any of its page-table entries that refer to this page. This is easy for a library operating system to do when it deal locates a resource in reaction to an exokernel revocation request. An abort protocol (discussed below) allows relocation to be performed when an exokemel forcibly reclaims a resource.

The Abort Protocol. An exokemel must also be able to take resources from library operating systems that fail to respond satisfactorily to revocation requests. An exokemel can define a second stage of the revocation protocol in which the revocation request (“please return a memory page”) becomes an imperative (“return a page within 50 microseconds”). However, if a library operating system fails to respond quickly, the secure bindings need to be broken “by force.” The actions taken when a library operating system is recalcitrant are defined by the abort protocol.

For example, consider about memory, secure binding use Multiplexing Physical Memory. Secure bindings to physical memory are implemented in our prototype exokemel using self-authenticating capabilities and address translation hardware. When a library operating system allocates a physical memory page, the exokemel creates a secure binding for that page by recording the owner and the read and write capabilities specified by the library operating system. The owner of a page has the power to change the capabilities associated with it and to deal locate it. To ensure protection, the exokernel guards every access to a physical memory page by requiring that the capability be presented by the library operating system requesting access. If the capability is insufficient, the request is denied. Typically, the processor contains a TLB, and the exokemel must check memory capabilities when a library operating system attempts to enter a new virtual-to-physical mapping. To improve library operating system performance by reducing the number times secure bindings must be established, an exokemel may cache virtual-to-physical mappings in a large software TLB. If the underlying hardware defines a page-table interface, then an exokemel must guard the page table instead of the TLB. Although the details of how to implement secure memory bindings will vary depending on the details of the address translation hardware, the basic principle is straightforward: privileged machine operations such as TLB loads and DMA must be guarded by an exokemel. As dictated by the exokernel principle of exposing kernel book-keeping structures, the page table should be visible (read only) at application level.

Consider about CPU. Aegis represents the CPU as a linear vector, where each element corresponds to a time slice. Time slices are partitioned at the clock granularity and can be allocated in a manner similar to physical memory. Scheduling is done “round robin” by cycling through the vector of time slices. A crucial property of this representation is position, which encodes an ordering and an approximate upper bound on when the time slice will be run. Position can be used to meet deadlines and to tradeoff latency for throughput. For example, along-running scientific application could allocate contiguous time slices in order to minimize the overhead of context switching, while an interactive application could allocate several equidistant time slices to maximize responsiveness.

Second Question:

Exokernels separate protection from management: they protect resources but delegate management to applications. For example, each application manages its own disk block cache, but the exokernel allows cached pages to be shared securely across all applications. Thus, the exokernel protects pages and disk blocks, but applications manage them.

To provide an interface that is as low-level as possible (ideally, just the hardware interface), an exokemel designer has a single overriding goal: to separate protection from management. For instance, an exokemel should protect frame buffers without understanding windowing systems and disks without understanding file systems.

I think the core of exokernel is that exokernel don’t provide abstraction to applications, and make applications management hardware resource more. For this purpose ,exokernel should protect applications and libos against each other. The goal is to achieve the implementation of exokernel. It makes applications and kernel have different works and make sure that they won’t interfere with each other.

Q3: Open question - do you think why has not Exokernel been as popular as monolithic kernel (Linux) and Hybrid kernel (Windows NT)?

Firstly, I think exokernel is too complex to most programmers. When programmers develop an application on exokernel , it need more skills and knowledge about OS and kernel and others. So far, the average ability of programmers can’t get the point of exokernel. Most of us are willing to use monolithic kernel and hybrid kernel OS to develop and test.

Secondly, there isn’t a commercial exokernel OS in the market. Software depends on market. There is no need to use exokernel because the performance of traditional OS like Linux and Windows can be accepted and they are successful on business.

At last , the performance of exokernel and some principle need further verification and improvement. It can’t be popular as mature and traditional OS.

王帅（软件学院14级研究生，0140379003）

Part Ⅰ: Before Reading this paper

Because of the lack of related fundamental knowledge in this field, I didn’t hurry to start the reading task. Instead, I searched for some knowledge about OS kernels and some basic definitions about Exokernel System.

Part Ⅱ: While Reading this paper

Some important points:

  • In most traditional operating systems, only the kernel and privileged servers can manage the resources, so we have to design an interface that is so versatile that it can satisfy all kinds of needs by variety of applications ( unfeasible and high-cost mistakes &&&& but why don’t we design different interfaces? ).
  • Exokernels separate protection from management: they protect resources but delegate management to applications.
  • LibOSes
  • Exoternel principles
    • Separate resource protection and management
    • Expose allocation
    • Expose names
    • Expose revocation
    • Expose information
  • Protected sharing mechanisms
  • File system design

Part Ⅲ: After Reading this paper

According the PROSEC analysis method(Actually I don’t know whether it virtually exists), the paper can be interpreted as follows,

Problem: In most operating systems only privileged servers and the kernel can manage system resources. Un-trusted applications are required to interact with the hardware via some abstraction model, the interface should be designed versatile enough to anticipate all possible needs. The exokernel architecture delegates resource management to user applications, the performance should be improved.

Related work:

  1. Push the kernel interface closer to the hardware
  2. Virtual machines
  3. Allowing applications to download code into the kernel
  4. User-level networking
  5. Application-controlled virtual memory
  6. All of the work above is applicable to liboses.

Observation: The exokernel architecture delegates resource management to user applications, this paper describes an exokernel system that allows specialized applications to achieve high performance without sacrificing the performance of unmodified UNIX programs(using liboses),

Solution: Using exokernel with specialized applications( or usual applications with liboses)

Evaluation: Evaluation of exokernel is done by comparing end to end application performance on Xok and two widely used 4.4BSD UNIX Systems (FreeBSD and OpenBSD). The results show that most unmodified UNIX applications perform comparably on Xok/ExOS and on FreeBSD or OpenBSD.Some applications, however, run up to a factor of four faster on Xok/ExOS. Experiments with multiple applications running concurrently also show that exokernels can offer competitive global system performance. Specialized applications such as Cheetah, gives remarkable performance improvement.

Comments: The design of exokernel is eminent, it put as much work as possible in to user-lever, separates resource management and protection, protects the resource but delegates management to applications, which means more flexibility and better performance with specialized applications, however, followed by complexity increase. How to design and implement the applications and the kernel interfaces becomes a huge challenge. Also, getting the right abstractions and writing reliable codes for exokernel are daunting tasks. All in all, it’s a great work needing to be further developed.

Part Ⅳ: My views on the questions post

Q1: Application can gain a better performance of memory and file system in Exokernel compared with microkernel or monolithic kernel, why? And what's the price of performance profit?

The exokernel separates resource management from protection, it gives much more control over hardware and software resource to un-trusted applications, with more controls and flexibility, applications can better manage the resources to get a better performance because the applications should know better how they will use the resource. The principle using physical names whenever possible also helps, physical names capture useful information and do not require potentially costly or race-prone translations from virtual names. Since user-level is more functional, less system calls also help improve the performance.

Price: increased complexity, the kernel interface design will be very difficult and it usually takes several iterations and several years to get a satisfactory interface. Applications with prominent performance improvement are those specialized ones(a few), those untuned ones(the majority) usually don’t have a obvious performance improvement. Only Application-level control can significantly improve the performance of the apps. Since the developers have to design the applications and even the libOSes to manage the resources, the code reliability may also be a problem. On the other hand, poorly chosen abstractions may cause lose of information. I believe only a few developers are interested about developing applications for such systems.

Q2: Exokernel grants the applications more control over hardware resource. How does Exokernel protect application/libos against each other? Please consider CPU, memory and storage. And how to understand this goal of paper:to separate protection from management?

While exokernels allow direct access to low-level resources, exokernel systems must be able to provide UNIX-like protection, including access control on high-level objects where required for security. To find kernel interfaces that allow such higher-level access control without either mandating a particular implementation or hindering application control of hardware resources, the exokernel example, Xok is designed using the following 3 techniques,

  1. Access control on all resources is uniform
  2. Bind hardware together with software abstractions
  3. Allow downloaded code where necessary, and protect it

The exokernel provides four mechanisms libOSes can use to maintain invariant in shared abstractions.

  1. Software regions (areas of memory that can only be read or written through system calls)
  2. Hierarchically-named capabilities(Requires that these capabilities to be specified explicitly on each system call)
  3. Wake-up predicates.(wake up processes when arbitrary conditions become true)
  4. Robust critical sections (implemented by disabling software interrupts)

Also, the exokernel provides 3 levels of trust in the shared abstraction.

  1. Mutual trust
  2. Unidirectional trust
  3. Defensive programming for mutual distrust

On the other hand ,as the authors portrait, the design of the file system, XN, takes the the consistency issues into consideration, this also helps.

As for how to understand the goal of paper, Separating protection from management is the method exokernel chose to solve the problem of the traditional OS, i.e. the drawbacks of implementing a versatile interfaces to anticipate all kinds of needs. By separating protection from management, the kernel still is responsible for the resource protection while gives resource management to applications. In this way, applications can be customized according to its needs, making better use of the limited resources to get better performance.

Q3: Open question - do you think why has not Exokernel been as popular as monolithic kernel (Linux) and Hybrid Ⅴkernel (Windows NT)?

In my point of view, Exokernel is more conceptual and not mature enough, we can not deny that this is a novel design, however, whether it can be popularized depends not only on its performance, we have to consider the ease of use, user-friendliness, etc. A great accomplishment of Exokernel is that users can customize applications and the liboses to get better performance, but is is an arduous task. Specialized applications can get better performance, but building a specialized application seems to be quite difficult. You have to consider as comprehensive as possible, even you have to design the file system, the protocols and so on. Maybe great inventions are for the minority. As the flexibility, performance improves, the difficulty raises, the complexity increases.