Commit 1dc2684e authored by Ticki's avatar Ticki
Browse files

Various improvements to wording and formulation

parent b27b2b54
......@@ -11,8 +11,6 @@ Any modern operating system needs basic security mechanisms such as virtualizati
* putting CPU in another mode (kernel mode, user mode)
* restoring callee registers (callee: process invoked by syscall or IPC)
These operations take some time and might be happening more than once. On microkernel systems this time adds up since compared to a monolithic kernel functionality is split off in several processes, often requiring several context switches to do the same task.
These are not necessarily slower on microkernels, instead microkernels suffers from having the need to perform these operations more frequently, due to many of the system functionality is performed by userspace processes, often requiring additional context switches.
With a good approach and some time spend optimizing for performance this should be a minimal issue, but Redox is not there yet.
See also: [Wikipedia on performance of minikernels](https://en.wikipedia.org/wiki/Kernel_%28operating_system%29#Performance)
To this date, microkernels have marginalized the performance difference between monolithic and microkernels, making the performance comparable. This is partly due to a smaller surface area, which can be more manageable to optimize. Unfortunately, Redox isn't quite there yet, we do still have a relatively slow kernel, since not much time have been spend on optimizing it.
......@@ -3,4 +3,4 @@ Heartbleed: A case study
Heartbleed is probably the most well-known safety related vulnerability. It was an exploit, which were simply created by a buffer overf
> TODO
<!-- > TODO -->
......@@ -24,7 +24,9 @@ Redox's kernel is a microkernel. The architecture is largely inspired by MINIX.
In contrast to Linux or BSD, Redox has only 16,000 lines of kernel code, a number that is often decreasing. Most services are provided in userspace
Having vastly smaller amounts of code in the kernel makes it easier to find and fix bugs/security issues more efficiently. Andrew Tanenbaum (author of MINIX) said that for every 1,000 lines of (good written) code, there is a bug. This means that for a monolithic kernel which could average over 15,000,000 lines of code, there could be at least 15,000 bugs. A micro kernel which usually averages 15,000 lines of code would mean that at least 15 bugs exist.
Having vastly smaller amounts of code in the kernel makes it easier to find and fix bugs/security issues more efficiently. Andrew Tanenbaum (author of MINIX) stated that for every 1,000 lines of properly written code, there is a bug. This means that for a monolithic kernel which could average over 15,000,000 lines of code, there could be at least 15,000 bugs. A micro kernel which usually averages 15,000 lines of code would mean that at least 15 bugs exist.
It should be noted that the extra lines are simply based outside of kernel space, making them less dangerous, not necessarily a smaller number.
The main idea is to have components and drivers that would be inside a monolithic kernel exist in user space and follow the Principle of Least Authority (POLA). This is where every individual component is:
* Completely isolated in memory and as separate user processes.
......
Unsafes
=======
`unsafe` is a way to tell Rust that "I know what I'm doing!", which is necessary when writing low-level code. You cannot write a kernel without `unsafe`s.
`unsafe` is a way to tell Rust that "I know what I'm doing!", which is often necessary when writing low-level code, providing safe abstractions. You cannot write a kernel without `unsafe`s.
In that light, a kernel cannot be 100% safe, however the unsafe parts have to be marked with an `unsafe`, which keeps the unsafe parts segregated from the safe code. We seek to eliminate the `unsafe`s where we can, and when we use `unsafe`s, we are extremely careful.
......
......@@ -17,6 +17,8 @@ We want to improve the security design when compared to other Unix-like kernels
The non-goals of Redox
----------------------
We are not a Linux clone, or POSIX-compliant, nor are we crazy scientists, who wants to redesign everything. Generally, we stick to the well-tested and proven correct designs. If it ain't broken don't fix it.
We are not a Linux clone, or POSIX-compliant, nor are we crazy scientists, who wishes to redesign everything. Generally, we stick to the well-tested and proven correct designs. If it ain't broken don't fix it.
This means that a large number of standard programs and libraries will be compatible with Redox. Some things that do not align with our design decisions will have to be ported.
The key here is the trade off between correctness and compatibility. Ideally, you should be able achieve both, but unfortunately, you can't always do so.
......@@ -28,3 +28,5 @@ Building on top of Redox, whether it gets to upstream or not, is a thing we appr
---------------------------------------------------------------------------------------
We like to have a decentralized structure of the project, allowing people to do whatever they want, no matter how they intend to share it.
Copyleft licenses are upstream-centric, whereas permissive licenses can be thought of as more downstream-centric. We happen to prioritize downstream more than upstream.
......@@ -6,7 +6,7 @@ A natural question this raises is: why do we need yet another OS? There are plen
The answer is: you don't. No-one _needs_ an OS.
Why not contribute somewhere else? Linux? BSD? MINIX?
-------------------------------------------------------------------------------------------------
-----------------------------------------------------
### Linux
There are numerous other OS's, kernels, whatever that lack for contributors, and are in desperate need of more coders. Many times, this is for a good reason. Failures in management, a lack of money, inspiration, or innovation, or a limited set of applications have all caused projects to dwindle and eventually fail.
......@@ -26,21 +26,21 @@ It is no secret that we're more in favor of BSD, than Linux (although most of us
BSD isn't quite there yet:
- It still has a monolithic kernel. This means that a single buggy driver can crash, hang, or cause damage to the system.
- The use of C in the kernel makes it probable to write code with memory safety issues
- Driver support, when compared to Linux, is poor
- It still has a monolithic kernel. This means that a single buggy driver can crash, hang, or, in worst case, cause damage to the system.
- The use of C in the kernel makes it probable to write code with memory safety issues.
### MINIX
And what about MINIX? It's microkernel design is a big influence on the Redox project, especially for reasons like [reliability](http://wiki.minix3.org/doku.php?id=www:documentation:reliability). MINIX is the most in line with Redox's philosophy. It has a similar design, and a similar license.
- Use of C - again, we would like drivers and the kernel to be written in Rust, to improve readability and organization, and to catch more potential safety errors
- Lack of driver support - MINIX does not work well on real hardware
- Use of C - again, we would like drivers and the kernel to be written in Rust, to improve readability and organization, and to catch more potential safety errors. Compared to monolithic kernels, Minix is actually a very well-written and manageable code base, but it is still prone to memory unsafety bugs, for example. These classes of bugs can unfortunately be quite fatal, due to their unexpected nature.
- Lack of driver support - MINIX does not work well on real hardware, partly due to having less focus on real hardware.
- Less focus on "Everything is a File" - MINIX do focus less on "Everything is a File" than various other operating system, like Plan9. We are particularly focus on this idiom, for creating a more uniform program infrastructure.
The Need for Something New
--------------------------
I will admit, I like the idea of writing something that is my own (Not Invented Here syndrome). There are numerous places in the MINIX 3 source code where I would like to make changes, so many that perhaps a rewrite in Rust makes the most sense.
We have to admit, that we do like the idea of writing something that is my own (Not Invented Here syndrome). There are numerous places in the MINIX 3 source code where I would like to make changes, so many that perhaps a rewrite in Rust makes the most sense.
- Different VFS model, based on URLs, where a program can control an entire segmented filesystem
- Different driver model, where drivers interface with filesystems like network: and audio: to provide features
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment