Commit 7f788635 authored by Coleman McFarland's avatar Coleman McFarland 💻
Browse files

Merge branch 'master' into 'master'

Cleaned up Introduction

See merge request !156
parents 41eb969b b0a7d4d6
Pipeline #7023 passed with stage
in 14 seconds
......@@ -3,14 +3,11 @@
- [Introduction](./introduction/welcome.md)
- [What is Redox?](./introduction/what_is_redox.md)
- [Our Goals](./introduction/our_goals.md)
- [Why a New OS?](./introduction/why_redox.md)
- [Our Philosophy](./introduction/philosophy.md)
- [Redox vs. Other Operating Systems](./introduction/how_redox_compares_to_other_operating_systems.md)
- [Why a New OS?](./introduction/why_redox.md)
- [Comparing Redox to Other OSes](./introduction/how_redox_compares_to_other_operating_systems.md)
- [Why Rust?](./introduction/why_rust.md)
- [Unsafes](./introduction/unsafes.md)
- [The Redox community](./introduction/community.md)
- [Side projects](./introduction/side_projects.md)
- [Projects maintainers](./introduction/maintainers.md)
- [Side projects](./introduction/side_projects.md)
- [Getting started](./getting_started/getting_started.md)
- [Trying Redox in a virtual machine](./getting_started/try_vm.md)
......
The Redox community
===================
We are quite a few developers at Redox. 40+ people work on it. There are all sorts of cool people to work with.
The "core team" (people who are members of the [GitLab organization](https://gitlab.redox-os.org/redox-os)) is currently:
(alphabetically sorted)
- [alicemaz]
- [arcterus]
- [aurelien-git]
- [batonius]
- [ca1ek]
- [cwood1]
- [dlrobertson]
- [hauleth]
- [ids1024]
- [jackpot51] (Our [BDFL])
- [k0pernicus]
- [mgattozzi]
- [mmstick]
- [movingtomars]
- [nounoursheureux]
- [polymetric1]
- [pythoneer]
- [sajattack]
- [skylerberg]
- [stratact]
- [ticki]
Some of those developers maintain several projects.
If you are looking to contribute to a project, you can contact the developer who is responsible that maintain the project using [this list].
But [don't]. [forget]. [all]. [the]. [other]. [awesome]. [contributors].
[BDFL]: https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
[alicemaz]: https://github.com/alicemaz
[arcterus]: https://github.com/arcterus
[aurelien-git]: https://github.com/aurelien-git
[batonius]: https://github.com/batonius
[ca1ek]: https://github.com/ca1ek
[cwood1]: https://github.com/cwood1
[dlrobertson]: https://gitlab.redox-os.org/dlrobertson
[hauleth]: https://github.com/hauleth
[ids1024]: https://gitlab.redox-os.org/ids1024
[jackpot51]: https://gitlab.redox-os.org/jackpot51
[k0pernicus]: https://github.com/k0pernicus
[mgattozzi]: https://github.com/mgattozzi
[mmstick]: https://gitlab.redox-os.org/mmstick
[movingtomars]: https://github.com/movingtomars
[nounoursheureux]: https://github.com/nounoursheureux
[polymetric1]: https://github.com/polymetric1
[pythoneer]: https://github.com/pythoneer
[sajattack]: https://gitlab.redox-os.org/sajattack
[skylerberg]: https://github.com/skylerberg
[stratact]: https://gitlab.redox-os.org/stratact
[ticki]: https://github.com/ticki
[this list]: ./maintainers.html
[don't]: https://gitlab.redox-os.org/redox-os/redox/graphs/master
[forget]: https://gitlab.redox-os.org/redox-os/coreutils/graphs/master
[all]: https://gitlab.redox-os.org/redox-os/sodium/graphs/master
[the]: https://gitlab.redox-os.org/redox-os/ion/graphs/master
[other]: https://gitlab.redox-os.org/redox-os/orbtk/graphs/master
[awesome]: https://gitlab.redox-os.org/redox-os/orbclient/graphs/master
[contributors]: https://gitlab.redox-os.org/redox-os/redox/graphs/master
......@@ -11,29 +11,29 @@ Compared to Linux, our syscall interface is much more minimal. This is not becau
### "Everything is a URL"
This is an generalization of "Everything is a file", largely inspired by Plan 9. In Redox, "resources" (will be explained later) can be both socket-like and file-like, making them fast enough for using them for virtually everything.
This is an generalization of "Everything is a file", largely inspired by Plan 9. In Redox, "resources" (*TODO: link*) can be both socket-like and file-like, making them fast enough to use for virtually everything.
This way we get a more unified system API. We will explain this later, in [URLs, schemes, and resources].
This way, we get a more unified system API. We will explain this later, in [URLs, schemes, and resources].
### The kernel
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 user space
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 user space.
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.
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 with nearly 25,000,000 lines of code, there could be nearly 25,000 bugs. A microkernel with only 16,000 lines of code would mean that around 16 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
* Completely isolated in memory and as a separate user process
* The failure of one component does not crash other components
* Allows foreign and untrusted code to not expose the entire system
* Foreign and untrusted code does not expose the entire system
* Bugs and malware cannot spread to other components
* Has restricted communication with other components
* Doesn't have Admin/Super-User privileges
* Bugs are moved to user space which reduces their power
All of this increases the reliability of the system significantly. This would be useful for mission-critical applications and for users that want minimal issues with their computer systems.
All of this increases the reliability of the system significantly. This is useful for mission-critical applications and for users that want minimal issues with their computer systems.
[URLs, schemes, and resources]: ../design/urls_schemes_resources.html
Maintainers
===========
Currently, [jackpot51] maintains:
- [The kernel, drivers, standard library, and Orbital]
- [The installer]
- [RedoxFS]
- [Newlib and C ports]
- [Orbclient]
- [OrbTK] (with assistance from [stratact])
- [Orbutils]
- [pkgutils]
- The overall direction of the project.
[ticki] maintains:
- [Binutils]
- [Coreutils]
- [Extrautils]
- [The project "Games for Redox"]
- [Libextra]
- [Ralloc]
- [Sodium]
- [TFS, a next-generation file system]
[mmstick] maintains the [Ion Shell].
[jackpot51]: https://gitlab.redox-os.org/jackpot51
[mmstick]: https://gitlab.redox-os.org/mmstick
[stratact]: https://gitlab.redox-os.org/stratact
[ticki]: https://gitlab.redox-os.org/ticki
[The kernel, drivers, standard library, and Orbital]: https://gitlab.redox-os.org/redox-os/redox
[The installer]: https://gitlab.redox-os.org/redox-os/installer
[RedoxFS]: https://gitlab.redox-os.org/redox-os/redoxfs
[Newlib and C ports]: https://gitlab.redox-os.org/redox-os/libc
[Orbclient]: https://gitlab.redox-os.org/redox-os/orbclient
[OrbTK]: https://gitlab.redox-os.org/redox-os/orbtk
[Orbutils]: https://gitlab.redox-os.org/redox-os/orbutils
[pkgutils]: https://gitlab.redox-os.org/redox-os/pkgutils
[Ralloc]: https://gitlab.redox-os.org/redox-os/ralloc
[Coreutils]: https://gitlab.redox-os.org/redox-os/coreutils
[Sodium]: https://gitlab.redox-os.org/redox-os/sodium
[TFS, a next-generation file system]: https://gitlab.redox-os.org/redox-os/tfs
[Tedsta]: https://gitlab.redox-os.org/tedsta
[Libextra]: https://gitlab.redox-os.org/redox-os/libextra
[Binutils]: https://gitlab.redox-os.org/redox-os/binutils
[Extrautils]: https://gitlab.redox-os.org/redox-os/extrautils
[The project "Games for Redox"]: https://gitlab.redox-os.org/redox-os/games
[Ion Shell]: https://gitlab.redox-os.org/redox-os/ion
......@@ -12,6 +12,7 @@ Redox OS is predominately MIT X11-style licensed, including all software, docume
- Faba and Moka icons, which are GPLv3
- Newlib C library, [which is a number of free software licenses, mostly BSD](https://github.com/bminor/newlib/blob/master/COPYING.NEWLIB)
- NASM, which is BSD 2-clause
*TODO: update*
The MIT X11-style license has the following properties:
- It gives you, the user of the software, complete and unrestrained access to the software, such that you may *inspect*, *modify*, and *redistribute* your changes
......@@ -20,6 +21,7 @@ The MIT X11-style license has the following properties:
- *Redistribution* Anyone may redistribute the software to patch the security vulnerabilities
- It is compatible with GPL licenses - Projects licensed as GPL can be distributed with Redox OS
- It allows for the incorporation of GPL-incompatible free software, such as OpenZFS, which is CDDL licensed
- The microkernel architecture means that driver maintainers could choose their own free software license to meet their needs
The license does not restrict the software that may run on Redox, however -- and thanks to the microkernel architecture, even traditionally tightly-coupled components such as drivers can be distributed separately, so maintainers are free to choose whatever license they like for their projects.
......@@ -29,7 +29,7 @@ We also actively contribute to third party projects that are heavily used in Red
What tools are fitting for the Redox distribution?
-------------------------------------------------
Some of these tools will in the future be moved out of the default distribution, into seperate optional packages. Examples of these are Orbital, OrbTK, Sodium, and so on.
Some of these tools will in the future be moved out of the default distribution, into separate optional packages. Examples of these are Orbital, OrbTK, Sodium, and so on.
The listed tools fall into three categories:
......
Unsafes
=======
`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.
A quick grep gives us some stats: the kernel has about 70 invocations of `unsafe` in about 4500 lines of code overall.
This contrasts with kernels written in C, which cannot make guarantees about safety without costly formal analysis.
You can find out more about how `unsafe` works in the [relevant section of the Rust book](https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html).
......@@ -3,7 +3,7 @@ Welcome!
This is the Redox book, which will go through (almost) everything about Redox: design, philosophy, how it works, how you can contribute, how to deploy Redox, and much more.
This book was written by Ticki with the help of LazyOxen, Steve Klabnik, ElijahCaine, and Jackpot51.
*Please note that this book is currently being (re)written.*
If you want to skip straight to trying out Redox, see [getting started](../getting_started/getting_started.html).
If you want to skip straight to trying out Redox, see [Getting started](../getting_started/getting_started.html).
......@@ -14,17 +14,11 @@ At this time, Redox supports:
* E1000 or RTL8168 network cards.
* Intel HDA audio controllers.
* Mouse and keyboard with PS/2 emulation.
*TODO: update*
This book is broken into the following chapters:
- [Introduction]: Explanation of what Redox is and how it compares to other systems.
- [Getting started]: Compiling and running Redox.
- [The design]: An in-depth introduction to the design and implementation of Redox.
- Development in user space: Writing applications for Redox.
- [Contributing]: How you can contribute to Redox.
- Understanding the codebase: For familiarizing yourself with the codebase.
- Fun: Top secret chapter.
- The future: What Redox aims to be.
*TODO*
It is written such that you do not need any prior knowledge in Rust and/or OS development.
......@@ -32,7 +26,7 @@ It is written such that you do not need any prior knowledge in Rust and/or OS de
[POSIX]: https://en.wikipedia.org/wiki/POSIX
[Plan9]: http://9p.io/plan9/index.html
[Minix]: http://www.minix3.org/
[Linux]: https://en.wikipedia.org/wiki/Linux
[Linux]: https://www.linuxfoundation.org
[BSD]: http://www.bsd.org/
[Design]: ../design/design.html
......
......@@ -9,18 +9,18 @@ Let's consider 3 existing projects.
### Linux
Linux runs the world, and boots on everything from high performance servers to tiny embedded devices. And many Redox community members run Linux as their main workstations. But Linux is not an ideal platform for new innovation in OS development.
Linux runs the world, and boots on everything from high performance servers to tiny embedded devices. Indeed, many Redox community members run Linux as their main workstations. However, Linux is not an ideal platform for new innovation in OS development.
- Legacy until infinity: Old syscalls stay around forever, drivers for long-unbuyable hardware stay in the kernel as a mandatory part. While they can be disabled, running them in kernel space is unnecessary, and can be a source of system crashes, security issues, and unexpected bugs.
- Legacy until infinity: Old syscalls stay around forever, drivers for long-unbuyable hardware stay in the kernel as mandatory parts. While they can be disabled, running them in kernel space is unnecessary, and can be a source of system crashes, security issues, and unexpected bugs.
- Huge codebase: To contribute, you must find a place to fit in to nearly _25 million lines of code_, in just the kernel. This is due to Linux's monolithic architecture.
- Non-permissive license: Linux is licensed under GPL2, preventing the use of other free software licenses inside of the kernel. More on our use of the MIT X11-style license in [Why Free Software].
- Non-permissive license: Linux is licensed under GPL2, preventing the use of other free software licenses inside of the kernel.
- Lack of memory safety: Linux has had numerous issues with memory safety throughout time. C is a fine language, but for such a security critical system, C is difficult to use safely.
### BSD
It is no secret that we're more in favor of BSD. The BSD community has led the way in many innovations in the past 2 decades. Things like [jails] and [ZFS] yield more reliable systems, and other operating systems are still catching up.
But BSD doesn't meet our needs:
That said, BSD doesn't meet our needs either:
- It still has a monolithic kernel. This means that a single buggy driver can crash, hang, or, in the worst case, cause damage to the system.
- The use of C in the kernel makes it probable to write code with memory safety issues.
......@@ -42,10 +42,10 @@ We have to admit, that we do like the idea of writing something that is our own
- Different driver model, where drivers interface with filesystems like `network:` and `audio:` to provide features
- Different file system, RedoxFS, with a [TFS] implementation in progress
- User space written mostly in Rust
- Orbital, a new GUI
- [Orbital], a new GUI
[Why Free Software]: ./why_free_software.html
[jails]: https://www.freebsd.org/doc/handbook/jails.html
[ZFS]: https://www.freebsd.org/doc/handbook/zfs.html
[reliability]: http://wiki.minix3.org/doku.php?id=www:documentation:reliability
[TFS]: https://gitlab.redox-os.org/redox-os/tfs
[Orbital]: https://gitlab.redox-os.org/redox-os/orbital
......@@ -3,7 +3,7 @@ Why Rust?
Why write an operating system in Rust? Why even write in Rust?
Rust has enormous advantages, because for operating systems _safety matters_. A lot, actually.
Rust has enormous advantages, because for operating systems, _safety matters_. A lot, actually.
Since operating systems are such an integrated part of computing, they are a very security critical component.
......@@ -11,9 +11,9 @@ There have been numerous bugs and vulnerabilities in Linux, BSD, Glibc, Bash, X,
Design does matter, but so does implementation. Rust attempts to avoid these unexpected memory unsafe conditions (which are a major source of security critical bugs). Design is a very transparent source of issues. You know what is going on, you know what was intended and what was not.
The basic design of the kernel/user space separation is fairly similar to genuine Unix-like systems, at this point. The idea is roughly the same: you separate kernel and user space, through strict enforcement by the kernel, which manages memory and other critical resources.
The basic design of the kernel/user space separation is fairly similar to Unix-like systems, at this point. The idea is roughly the same: you separate kernel and user space, through strict enforcement by the kernel, which manages memory and other critical resources.
However, we have an advantage: enforced memory and type safety. This is Rust's strong side, a large number of "unexpected bugs" (for example, undefined behavior) are eliminated.
However, we have an advantage: enforced memory and type safety. This is Rust's strong side -- a large number of "unexpected bugs" (for example, undefined behavior) are eliminated at compile time.
The design of Linux and BSD is secure. The implementation is not:
......@@ -26,6 +26,18 @@ Click on the above links. You'll probably notice that many are bugs originating
We hope that using Rust will produce a more secure operating system in the end.
### Unsafes
`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.
A quick grep gives us some stats: the kernel has about 300 invocations of `unsafe` in about 16,000 lines of code overall. Every one of these is carefully audited to ensure correctness.
This contrasts with kernels written in C, which cannot make guarantees about safety without costly formal analysis.
You can find out more about how `unsafe` works in the [relevant section of the Rust book](https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html).
[Linux kernel vulnerabilities]: https://www.cvedetails.com/vulnerability-list.php?vendor_id=33&product_id=47&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=7&cvssscoremax=7.99&year=0&month=0&cweid=0&order=3&trc=269&sha=27cc1be095dd1cc4189b3d337cc787289500c13e
[Glibc vulnerabilities]: https://www.cvedetails.com/vulnerability-list.php?vendor_id=72&product_id=767&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=62&sha=5e0c40399ffafd65f77e6b537bcc0f50474eeed3
......
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