PURE Mid-Progress Report Ranran Li, Priya Mehta Mentor: Nathan Dautenhahn
PerspicuOS The nested kernel is the architecture for an operating system, in which two levels of privilege exist. PerspicuOS is the prototype of this system and was created by modifying FreeBSD 9.0. The MMU is separate from the rest of the kernel in order to allow for these different privilege levels. So the problem that we are dealing with at a high level is that existing monolithic kernels trust a very large set of code, which has been shown susceptible to attack. The nested kernel seeks to reduce the trusted computing base (TCB) of the system so that the amount of trusted and potentially vulnerable code is greatly reduced.
Buddy Allocator The buddy allocator works by dividing memory into partitions based on given memory requests. Each block of memory has a specific order, ranging from 0 to an upper limit. When a larger block of memory is split, it becomes two smaller equally-divided blocks, which are considered to be "buddies" of each other. A block that is split can only merge with its “buddy” if both are free and can be merged back into a larger block.
Necessity of Buddy Allocator in PerspicuOS Because PerspicuOS is isolated from the operating system it must manage its own internal memory, and the current implementation does not have a dynamic memory allocator. The specific benefit is that we will be able to reclaim memory efficiently in both space and time, but more importantly, we will be able to dynamically grow the region of space available to PerspicuOS for protecting memory in the overall system.
What we have learned and done so far First, we completed a git tutorial. We’ve learned the basics of git, including push, pull, etc. We use github to share all of our code and documents. Then we learned about the buddy memory allocator which is going to be used within the PerspicuOS nested kernel. The nested kernel buddy allocator will have three functional interfaces: initialize, allocate, and free. To initialize, we have two linked lists of metadata on the stack to keep track of the freed and used memory. To allocate, we divide the big memory block in half until we find the best fit size, then alloc memory into that block.To free, we’ll merge the free block with its freed buddy to create a bigger free memory block. Diagram: We have a skeleton of the code which will support the above functionalities.
What needs to be done next We are going to choose an implementation for our code. We are going to choose a specific data structure, either binary tree or linked lists. After that, we will decide what will be the upper and lower bound for size of the memory block in our buddy allocator. Once this is done, we will finish coding the buddy allocator and implement it into the nested kernel.