Memory
The Vesper microkernel does not dynamically allocate memory for kernel objects. Instead, objects must be explicitly created from application-controlled memory regions via Untyped Memory capabilities. Applications must have explicit authority to memory (through these Untyped Memory capabilities) in order to create new objects, and all objects consume a fixed amount of memory once created. These mechanisms can be used to precisely control the specific amount of physical memory available to appli- cations, including being able to enforce isolation of physical memory access between applications or a device. There are no arbitrary resource limits in the kernel apart from those dictated by the hardware, and so many denial-of-service attacks via resource exhaustion are avoided.
At boot time, Vesper pre-allocates the memory required for the kernel itself, including the code, data, and stack sections (Vesper is a single kernel-stack operating system). It then creates an initial user thread (with an appropriate address and capability space). The kernel then hands all remaining memory to the initial thread in the form of capabilities to Untyped Memory, and some additional capabilities to kernel objects that were required to bootstrap the initial thread. These Untyped Memory regions can then be split into smaller regions or other kernel objects using the Vesper UntypedRetype() method; the created objects are termed children of the original untyped memory object.
The user-level application that creates an object using Vesper UntypedRetype() receives full authority over the resulting object. It can then delegate all or part of the authority it possesses over this object to one or more of its clients.
Untyped memory objects represent two different types of memory: general purpose memory, or device memory. General purpose memory can be untyped into any other object type and used for any operation on untyped memory provided by the kernel. Device memory covers memory regions reserved for devices as determined by the hardware platform, and usage of these objects is restricted by the kernel in the following ways:
- Device untyped objects can only be retyped into frames or other untyped objects; developers cannot, for example, create an endpoint from device memory.
- Frame objects retyped from device untyped objects cannot be set as thread IPC buffers, or used in the creation of an ASID pool.
The type attribute (whether it represents general purpose or device memory) of a child untyped object is inherited from its parent untyped object. That is, any child of a device untyped will also be a device untyped. Developers cannot change the type attribute of an untyped.
Also see L4's funky TLB-flush-cost-small-spaces address-space switcher. [Liedtke 1995]
On microkernel construction - Appendix A: An Abstract Model of Address Spaces
Процесс в Mach - это, в первую очередь, адресное пространство и набор нитей, которые выполняются в этом адресном пространстве. Таким образом, выполнение связано с нитями, а процессы являются пассивными объектами и служат для сбора всех ресурсов, использующихся группой взаимосвязанных нитей, в удобные контейнеры.
A passive address space is a memory protection entity in which arbitrary threads may execute - a Protection Domain (PD).
http://www.cse.unsw.edu.au/~disy/Mungi.html
SASOS - all memory addresses are "physical" (i.e. addresses 1000 and 1000 in two different tasks point to the same physical memory address).
The basic abstractions provided by Mungi are:
- capability,
- object,
- task,
- thread,
- and protection domain.
Objects are the basic storage abstraction. They consist of a contiguous range of pages, with no further structure imposed by the system. Objects are protected by capabilities which are described below.
Threads are the basic execution abstraction. A task is a set of threads which share a protection domain. A protection domain consists of a set of capabilities. Capabilities are presented implicitly by storing them in a special data-structure known to the system. This reduces the need for most applications to deal with capabilities and thus makes protection transparent.
Grasshopper [RDH+96] is a system specifically designed to support persistence. Its basic storage abstraction is called a container, which essentially constitutes an address space. Containers, or parts thereof, can be mapped into other containers. Grasshopper presents a generalized model of address spaces, which can emulate a traditional model, such as UNIX, as well as the SASOS model [LRD95].
A. Lindstrom, J. Rosenberg, and A. Dearle. The grand unified theory of address spaces. In Proceedings of the 5th Workshop on Hot Topics in Operating Systems (HotOS), pages 66-71, Orcas Island, WA, USA, May 1995. IEEE. [LRD95]
guarded page table (GPT) [Lie93,Lie96b].
