[CSE231 Paper Reading] ErOS

文章目录[隐藏]

Summary

  1. The motivation for the paper is the author wants an abstraction for checkpointing and object-based storage or memory system for a microkernel so that you can achieve its efficiency by fusing carefully selected abstract objects with methods of object caching. All programs with direct hardware access or the capacity to directly change the security state of the system is gathered in the kernel to make security assurance simpler. Thus, the single-levelstore and bottom-half device drivers are implemented in the kernel.

  2. Via capability-protected abstractions, the kernel offers a very direct virtualization of the underlying hardware. The size of the pages, which include both data and capabilities, is determined by the underlying hardware. Additionally stored in nodes are capabilities. Nodes have 32 capabilities and perform a similar function to metadata in traditional systems. Pages and nodes include all the information that applications can see. A capability that names the root of the process' address space tree is present in every EROS process. This tree's mapping is converted into the representation needed by the underlying hardware on demand. The EROS kernel makes any necessary object faults to load pages and nodes from the disk after trying to traverse the address space tree to construct a valid mapping when a page fault occurs. In the event that a valid mapping is discovered, it is added to the hardware mapping database and the process is repeated. If not, the problem is reported using an upcall to a user-level fault handler that is provided by the process or the address space, if any (otherwise). They have a virtual copy mechanism for page migration and address translation for faster page walk.

  3. The author proposed a fantastic result for the EROS. It is evident that EROS performs admirably on 6 of the 7 benchmarks. This, in our opinion, offers strong, if clearly not conclusive, evidence that the presence of protected subsystems (some of which were employed in the EROS benchmarks) need not adversely affect system performance. Furthermore, it seems that capability systems can operate effectively without the need for specialist hardware assistance.

Critique

  1. I generally believe in the experiment since it basically represent the pros of the experiment.
  2. It's art and science. It has abstractions for inter-process communication (IPC), virtual address spaces, threads, and, unlike most L4 kernels, authorization capabilities. Virtual address spaces do not have a kernel-defined structure; instead, page faults are conveyed via IPC to the pager threads in charge of creating the virtual address space by converting frames into it. To assist virtualization, exceptions and non-native system calls are also transmitted via IPC. IPC facilitates RPC through reply capabilities and uses synchronous and asynchronous endpoints (port-like destinations without in-kernel buffering) for inter-thread communication. Capability address spaces made up of capability container objects known as cnodes are used to separate and store capabilities.
  3. It's the beginning of the research, because it has the abstraction for IPC and circle out the machine state, which is the best for verification using LTL verfication technique.