Review: Application Performance and Flexibility on Exokernel Systems

From: Raz Mathias (razvanma_at_exchange.microsoft.com)
Date: Wed Jan 21 2004 - 14:53:11 PST

  • Next message: Tarik Nesh-Nash: ""Application Performance and Flexibility on Exokernel Systems" Review"

    This paper described an interesting system organization known as the Exokernel. Exokernels basically provide a minimal set of protection mechanisms necessary for implementing traditional kernel-mode operating system components in user mode. This paper makes a case for exokernels by demonstrating their performance characteristics combined with their extensibility and comparing them to monolithic kernels.

     

    Exokernels provide the lowest common denominator in protection while simultaneously exposing an interface as close to the hardware level as possible. They allow for keeping track of ownership and protected allocation and revocation of these low level resources. User-mode libOS's are libraries that take advantage of these exokernel abstractions to build higher-level abstractions (such as named file systems built upon protected disk blocks). The exokernel provides libOS'es with as much information as possible so that decisions which were traditionally made at the kernel level are now made safely and efficiently at the user level.

     

    The paper discusses four mechanisms for libOSes to manage, software regions (protected memory), named capabilities, wakeup predicates (kernel-downloaded, kernel-verified functions for detecting and generating events), and critical sections (as opposed to locks which lead to implementations that require trust between processes).

     

    The paper centers around XN the kernel-level implementation of a file system built around minimalist exokernel principles and C-FFS, a user-level file system libOS built on XN.

     

    One of the breakthroughs described in this paper is the use of UDF's, untrusted deterministic functions, which map higher-level file system metadata abstractions to lower level notions understood by XN. The UDF is implemented in a limited language and checked by the kernel. One use illustrated by the paper is to map high level file system metadata to lower level disk blocks that XN understands. Another similar type of function employed by XN is the UF, which has fewer guarantees than the UDF (note the missing D for deterministic). These functions are used in ACL checks and in computing the sizes of data structures on disk. Basically, these methods (collectively known as templates) allow the underlying OS to translate higher-level constructs into salient low-level information required for protection, without limiting their flexibility or performance.

     

    The paper outlines the functionality provided by XN allowing for flexible user-mode file system design. The first includes secure bindings moving access checks to bind time rather than every access (improving the performance of reads/writes). Next, XN uses UDF's to determine access rights to disk blocks. Next, the disk writes must be specially ordered to prevent applications from touching memory they don't own via uninitialized pointers. Notice that this third requirement does not prevent disk writes from being asynchronous.

     

    The paper then describes C-FFS, Unix-like file system on top of which various performance tests are run. The results of the performance tests are quite impressive, demonstrating improvements of up to an order of magnitude (e.g. in the Xok HTTP implementation versus the NCSA HTTP implementation).

     

    But as in all computer science solutions to difficult problems, something's always got to give. In this case, the complexity of the system increases with the performance. The paper states that it took them "several iterations" to get the system working. Even then, In this system, we can easily add file systems to the OS, but is this new possibility of real value given the increased complexity? I'm not completely convinced that the system is completely protected. To me, the fact that you can download code into the kernel conflicts with the extensibility goal. Either the system is easily extensible, in which case it should be easy to download code into the kernel leading to questionable security....or it's difficult to download code into the kernel (it needs to be signed, etc.) in which case the system is quite as extensible. The paper claims that the kernel checks the UDF's, but the UF's (used for ACL's) are not checked, and can potentially loop infinitely, thereby taking down the kernel.

     

    Despite its complexity, the performance benefits alone make this an idea worth investigating further.

     


  • Next message: Tarik Nesh-Nash: ""Application Performance and Flexibility on Exokernel Systems" Review"

    This archive was generated by hypermail 2.1.6 : Wed Jan 21 2004 - 14:54:10 PST