jgulian/rustos

RustOS: A Kernel for the Raspberry Pi

This project was done out of an interest in operating systems. As a base I used a previously offered course on operating systems at Georgia Tech, which is no longer offered. I completed all parts of the course excluding networking. I decided not to do networking because I would like to implement network drivers in safe rust instead of writing safe wrappers for unsafe c.

Current State

The current focus of the project over the past week has been moving away from the course and towards modern Rust features. After this, I will proceed with working on

Installing

Currently, the project is on 1.68.0-nightly. I'm working on making it easier to run on general (more) hardware, but for now qemu is recommended with the settings in the Makefile.

Roadmap

• Allow processes to open files
• Add more system calls read, write (beyond single characters), fork, exec, wait, and pipe (maybe more?)
• Implement shell and have stdin, stdout, and stderr
• Make the file system writable*
  • Move from the current c library to a rust library
• Add page swapping mechanisms
• Allow the stack to grow downwards (ie outside one page of memory)
• Use smaller pages
• Introduce a feature-rich IPC structure.
• Support ELF file format
• Add user space concurrency features (including locks, CVs, and semaphores)
• Work on a hosted hypervisor
• Networking
• Use cargo fuzz and miri to libraries for security.
• Update bootloader
• Create a mkfs tool to make filesystem without needing to worry about OS/architecture (like xv6-riscv)
• Use cargo clippy

* Asterisks suggest features are in a partially complete state, but require more work or coverage testing.

rustos's Issues

Fold libraries into several "core" libraries or the kernel

On 0.2.3, there are 13 libraries in the libs directory. Many of these libraries do very little. This isn't necessarily bad and indeed may have some benefits, but I feel the pros outweigh the cons.

Then, features will be folded into several packages.

• architecture
  • aarch64
  • possibly riscv (far future and will require abstraction for the kernel)
• hardware
  • HALs for raspberry pi or future devices
• persistent
  • filesytem traits
  • device traits
  • implementations like fat32 and possibly ext4
• standard
  • xmodem
  • elf
  • ip layout
  • mbr

There will remain a couple of other libraries.

• kernel_api (parts may be folded into the kernel)
• shim (Shim may be expanded or removed entirely; currently leaning towards expansion)
• allocator (likely split up again into userspace and kernel allocators because, after all, they're currently split)

As a general rule, I'm going to try and limit the amount of unsafe that leaves crates like architecture and hardware (but all crates more generally) and seeps into the kernel. I think this will have multiple benefits beyond (hopefully) limiting the safety issues like providing higher level interfaces to use, making adding more hardware or architecture (hopefully) easier.

Elf support

Currently, elf files are not supported. the OS doesn’t need to support every part of an elf file but forcing the user to run obj copy is bad. Also arguments and environment variables need to be migrated to the elf standard.

Move Existing Hardware implementations to HALs or other safer alternatives

Currently some of the hardware interfaces are most c like than rust like. this is obviously bad and needs to be changed.

Included in this is moving from the ffi sd card library to a rust ssd card library.

Cross-platform Development support

At the current point, portions of the development cycle only work on certain operating systems. For instance, building and objcopying needs to be done on windows* or macos, but building the image must be done on ubuntu. Windows may be able to do everything but I am unsure at this time.

It is desirable that everything works on every operating system. Looking into this will occur in the next refinement phase.

* building kernel works on windows but it is not known whether it works for user applications.