Baboon Operating System

Note: The goal was to take a un-popular kernel then build a very user friendly, functional, versatile, and generally easy to use system off of it
Design
Baboon os was a project thought up by Timothy Charles McDermott, Marcus Neil Dessek, and Nathan "no one actually knows his middle name" Micheals. The original idea was that ALL other kinds of kernels were popular except the exokernel witch you don't really ever hear about so Nathan did some studying into the subject and found that not only was it a mildly lean kernel in general but it could be sized to accommodate most systems, which was one of our main concerns because when something isn't popular theres usually a reason.
Features
1. User friendly
2. Simple
3. Diverse
4. Flexible to fit the consumers needs
5. Developing viruses for it is on the brink of impossible ( no viruses )
6. popular software available Firefox,Google Chrome,Gimp, ect.
7. file conversion and transfer C.T.F or convert traceable files (if your mac breaks down you can transfer all the files to your baboon brand computer and it will automatically convert the files to a format that the computer can read.)
Opening view on exokernels
On traditional operating systems only trusted software such as privileged servers or the kernel can manage resources.
This thesis proposes a new approach, the exokernel architecture, which makes resource management unprivileged but
safe by separating management from protection: an exokernel protects resources, while untrusted applicationlevel
software manages them. As a result, in an exokernel system, untrusted software (e.g., library operating systems) can
implement abstractions such as virtual memory, file systems, and networking.
The main thrusts of this thesis are: (1) how to build an exokernel system; (2) whether it is possible to build a real
one; and (3) whether doing so a good idea. Our results, drawn from two exokernel systems , show that the
approach yields dramatic benefits. For example, Xok, an exokernel, runs a web server an order of magnitude faster
than the closest equivalent on the same hardware, common unaltered Unix applications up to three times faster, and
improves global system performance up to a factor of five.
The thesis also discusses some of the unusual techniques we have used to remove the overhead of protection. The
most unusual technique, untrusted deterministic functions, enables an exokernel to verify that applications correctly
track the resources they own, eliminating the need for it to do so. Additionally, the thesis reflects on the subtle issues in
using downloaded code for extensibility and the sometimes painful lessons learned in building three exokernelbased
systems.
Press
there hasn't been very much press for this Operating System because its kind of been kept secret until recently whe the information and the screenshots were posted on a linux forum with the original screenshots
Development
1.Multiplexing Storage
goal: allow each app to have its own file system, but on the same disk, and share file
systems when needed. challenge: have to figure out which blocks would go with which file system
Actual solution: UDFs: untrusted deterministic functions. idea: don’t try to understand the metadata -- just make the file system tell you in a
consistent way what the references are. Usage: file system author writes a function for each template type, owns-udfT, and gives
it to the kernel, which verifies that it is deterministic. The kernel then uses this function
to verify every proposed change to a block, so that libOS can’t change references
without the kernels permission.
o owns-udfT(block) -> list of (block #, template type) pairs
This returns the (deterministic) set of pointers in the input block
o Example: to add a data block, d, to an i-node, i, you call something like:
XN_allocate(i, d, changes to i)
XN would create i’ by applying the changes to i, and would confirm that:
owns-udfT(i’) = owns-udfT(i) + d
Access control for pages:
done when a block is mapped into an address space -- which means you don’t need to
check it on every access (bind + fast access)
Must also deal with write ordering for persistence (read the paper for this)
root list keeps the root block for each file system, from which XN can build the whole
tree (using owns-udfT recursively)
Splitting was one solution for the task problem the idea of keeping a un-editable copy of the original and then within that copy of the original split it into two the active copy and the non active copy "a small price to pay for better performance, yes an intelligent idea, no."
splitting
idea copy all of the pages that are not the active data/stack pages via copy-on-write, but
handle the hard ones directly
Thought overview
Principles: Separate protection and management: use the lowest level required for protection,
ideally the hardware level (e.g. disk blocks). Types of calls: allocation/revocation,
sharing, tracking/changing ownership
Explicit allocation and revocation
Use physical names: avoid translation from virtual names (and its consistency problem)
Expose information: typically read-only access to kernel state for making decisions in
the libOS
Four basic tools: [slightly different than written in the paper!]
software regions: like Multics segments -- sub-page protection and fault isolation
hierarchical capabilities, which must be passed on most system calls
bind hardware resources together (e.g. disk block and page frame that holds it)
download code (that can be verified) to control some policies. E.g. wakeup predicates
determine if a process is ready to run (without waking it up)

Main Menu

See Also

Main Menu