Redox Development Did you get your iron today?

ISO Releases, New Forum, Docs

I have been working on the public website, and have added a new forum for users to use at:

https://discourse.redox-os.org

This is modeled after https://users.rust-lang.org and is completely open and allows anyone to sign up, unlike our mattermost chat.

I hope people who are interested will sign up and start posting.

There are also detailed kernel and libstd docs at https://doc.redox-os.org

We have an ISO release (WIP) at https://static.redox-os.org

Redox is Serious

You can build Redox on Linux, Windows, or OS X from the GitHub repository

I have been quiet for a while, not because I am introverted, but because I have been working very, very hard.

I want to show off some things that have come about over the course of the last week, with help from the Redox Team.

First off, I asked contributions to the kernel to be limited over the past few days, because I was planning a complete overhaul of the kernel. LazyOxen, k0pernicus, stratact, and Ticki made contributions that were integrated into the rewrite. There were several reasons for the rewrite, and now that the majority of the work is completed, I would like to explain why this is the most important set of changes in Redox history, because it means that Redox is Serious.

Problems

The following things were completely and totally possible in a program one week ago:

  • Access to IO ports
  • Access to kernel memory
  • Access to other processes's memory

Also, the following problems were present:

  • External input, correctly constructed, could crash the kernel
  • Schemes did not run in a context, and did not have resources tracked correctly
  • Program allocations were not tracked at all, allowing for memory leaks
  • The entire graphics stack (all the way to the desktop!) was inside of the kernel
  • Very low utility of the terminal
  • Very low portability of applications

Solutions

  • Start all user applications in usermode (ring 3)
  • Prevent all access to I/O ports in usermode
  • Prevent all access to memory not mapped for a process
  • Start all schemes as processes, and switch to a message passing system for IPC
  • Track allocations for every process, clean them up on exit, and map them on each context switch
  • Utilize a get_slice function to safely catch out of bound indexes
  • Improve process management, so that a list of processes can be seen, and crash dumps are more expressive
  • Move the graphics stack into the orbital scheme, accessed through F2
  • Create a Console struct to deal with the F1 console
  • Run the terminal app in the F1 console by default
  • Vastly improve the terminal app's commands
  • Improve the newlib Redox support
  • Create a port system to port a number of open source applications and libraries

Evidence

After these changes, Redox runs very well, and can be exercised through either the console or the desktop environment.

Here is the desktop enviroment, running on real hardware, with an SDL example showing:

undefined

The process list, at context:, will show kernel processes, schemes, and programs. Used memory and open file descriptors are shown

undefined

Here you can see, the test program can no longer write to random addresses or reboot the system!

 undefined

The network stack is fixed, much of it is in userspace, and it is working on real hardware! Here is Redox receiving pings

undefined

And my Ubuntu system sending pings

undefined

Finally, I am working on an installer!

undefined

There may be things I forgot in these lists. Also, ZFS support is very close to being ready to use in a real system.

 

P.S. Here is Redox only a month ago:

undefined

Edumacation

Welp, darn, ya'll done edumacated me. From reddit to twitter to hackernews, everybody's got ideas.

It's time to get serious on cleanup, because my code must be just as strong as my ego:

undefined

In conclusion, some of the areas to work on are:

  • Removing unsafe where possible
  • Using tests for kernel functionality and security
  • Window management
  • Ring 0/Ring 3 division
  • Drivers (most importantly PIO and MMIO structs)
  • Nobody mentioned it yet, but the filesystem is read-only!
  • Rust libstd Support

I will probably start with the driver cleanup, by moving PIO and MMIO into structs that encapsulate the unsafe and volatile operations.

Don't forget to leave comments below:

Feedback from Hackernews

Thread here: https://news.ycombinator.com/item?id=10295187

Yeah, I know, I'm not cool enough for hacker news. I know, Redox sucks. :-P

From nickpsecurity

The blog was a good read. I agree with acconsta that the description doesn't seem to utilize Rust's better attributes. Plus, that it's "starting to look like Linux" (author) may or may not be good. I'd look at Wirth's Oberon or A2 Bluebottle for a simpler start: type-safe, memory-safe (mostly), GC'd OS with good documentation, source available, and a simplicity focus for easy re-implementation. Rust, in theory, can do whatever it did and faster.
Additionally, if doing clean-slate, might be worth looking into alternative models for constructing or securing OS's. EROS security OS, SPIN OS's type-safe linking for acceleration, Minix 3's reliability scheme, JX OS's architecture, Microsoft's verified VerveOS scheme, maybe even Amoeba distributed OS just for kicks to see what it could do today. Lot of stuff that might be better than Linux model with a Rust implementation in terms of reliability, security, extensibility, or developer productivity.
Just a thought for Redox author or someone else wanting to try an OS in Rust. However, best thing to come out of Redox project, imho, isn't the OS so much as this article:
https://redox-os.org/index.php?controller=post&action=view&id_post=5
Great write-up on an equally great strategy of developing with hardware that's well-supported by both native OS's and virtualization. That's worth copying and expanding in other projects. Maybe worth a dedicated list like the HCL's where there's a list of computer builds that are easiest to develop on with or without virtualization. Or list it one piece of hardware at a time.

Screenshots

First, here is the GUI showing the apps at the bottom, a window list, a file manager, terminal, and image viewer. This is running in QEMU.

undefined

Next, this is the debug console (accessed by pressing F1, F2 will take you back to the GUI). I am running Lua here to demonstrate the C library (newlib)

undefined

Hey Guys

From the number of stars on github, I can see that this really took off!!! I am preparing a forum so that I can communicate with potential testers and contributers more easily.

I am very excited right now, I have been working hard on designing Redox and would love for more people to see what it can do, and how it works!

Preparing some screenshots now...

Home ← Older posts