Giter Site home page Giter Site logo

sunriseos / sunriseos Goto Github PK

View Code? Open in Web Editor NEW
222.0 11.0 13.0 39.38 MB

Horizon/NX kernel reimplementation

License: Apache License 2.0

Rust 99.47% Shell 0.02% Python 0.27% Makefile 0.22% Batchfile 0.03%
kernel osdev nintendo-switch nintendo horizon kfs

sunriseos's Introduction

sunriseos's People

Contributors

dependabot-preview[bot] avatar dependabot-support avatar dependabot[bot] avatar kitlith avatar orycterope avatar roblabla avatar zdimension avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sunriseos's Issues

Create a "Pio registry" from which we get Pio objects

Right now, Pios can be created at will with utter disregard for ownership. This isn't great. It'd be nice if we could statically guaranatee that a given pin will only be used once (and panic on duplicate use).

The idea would be to have a PioRegistry that keeps track of who uses which pins. This PioRegistry would keep a Vec (or HashMap or whatever) of Pio registration entries, and only return a Pio if it isn't already registered.

Use clippy on CI to get even more warnings

Because we clearly don't have enough warnings.

Clippy is a cool tool that's able to catch a lot of logic bugs, in addition to imposing some style choices (which helps keep the code uniform).

Rust 2018 here we come!

Rust 2018 has so many awesome feature, it'd be a shame if we missed out on them. We should upgrade to rust 1.31, and upgrade all our crates to the 2018 edition.

Use upstream font-rs

Return to vanilla font-rs, now that we're in userspace and have a heap.

This might need a PR to font-rs to expose a font's max_ascent and max_descent

bzero pages

The kernel must bzero every page that it gives to userspace, to prevent leaking data from a process to another.

Unfortunately this implies a lot of overhead. We should find a way to be smart about it, and do it the less often possible.

First we need to decide if either:

  • All allocated pages are bzero'd, no matter if it's for landing them to user, or for kernel internal use.
  • Only userspace pages are bzero'd before use. This means that the kernel can re-use old dirty userspace pages for its own use, which could facilitate kernel exploits. However since the kernel is supposed to be so small, and all services reside in userspace, this might be acceptable.

Secondly, we need to find a strategy to keep track of dirty pages, and bzero them only once.
I imagine we can put to use the dirty flag in the page tables, but i don't really know when would be the best moment to do the clean. On allocation ? On clean ?

Also: Do we consider never-used pages as clean ? Are they guaranteed to be all zeros on boot ?

A lot of questions ๐Ÿ˜•

CR0 WriteProtect bit

Apparently, if CR0 WP bit is not set, then the kernel can write in RO pages. We might want to set it.

Map kernel in high memory (> 0xC0000000)

We should map the kernel at the end of address space (> 0xC0000000).

This might be accomplished by a bootstrap stage whose main goal is to enable paging. It maps the rest of the kernel in high addresses, and jumps to it. That way the kernel starts with paging already on.

The bootstrap is also a good place to handle architecture specific things, like setting up a valid kernel stack, creating the gdt, etc.

Figure out the testing story for KFS

Our kernel is currently completely untested. We need to fix this. We should have two layers of tests:

  1. Unit tests, which would be ran using (more or less) cargo test, will check the core routines of our kernel (bookkeeping, IPC primitives, scheduling algorithm, etc...) to make sure they have the expected behavior.

  2. Integration tests, which would be either userspace binaries or "kernel processes" which would run under qemu and write the output of the test to the serial console.

The first layer is very easy to implement. We just need to add a few #[cfg] here and there, and write the damn tests.

The second layer is more interesting though. It will require adding a test harness to the kernel. The test harness will be responsible with running the tests (which should each be a single "Process" - either userspace or kernel) and outputing the results of the tests on the serial console. Ideally, it should output it in a format understood by the TAP protocol (https://testanything.org/), so that we can then use TAP consumers (such as tappy) to read the output easily. There is a crate that allows easily writing TAP producers: https://docs.rs/testanything/0.1.1/testanything/

Port libstd

We have a userspace. Next step is porting the libstd. This would allow us to use many of the nice interfaces from std, such as std::io, HashMaps, etc...

Corruption of vbe

Our kernel displays corrupted lines at the top of the screen.

screen shot 2018-06-30 at 2 56 09 pm

I suspect the frame allocator is to blame, giving us frames we shouldn't by writing to.

Safety of the vi::draw IPC method

When calling vi::draw, vi reads from the shared memory. There is no borrow-checking mechanism in place to ensure that the other process does not mutate it while this happens. Maybe we should have some kind of cross-process mutex? How to implement this properly?


https://github.com/roblabla42/KFS/blob/42d48b20bf345d877937578d7845304141937c9e/vi/src/main.rs#L109-L119


This issue was generated by todo based on a TODO comment in 42d48b2 when #52 was merged. cc @roblabla.

error types

Make kernel errors match the userspace errors.

Implement Serial Port

We lost the pretty CGA ๐Ÿ˜ญ . We'll need an easy low-level debugger for all the dumb shit that'll happen in the VBE stuff, and serial seems easy enough. Right? ๐Ÿ˜…

Frame: Implement Drop

Reserve a bit in the PageEntry for DROPPABLE, add a bool in Frame for droppable. If droppable is true, free the frame from the allocator.

Crash when IRQ triggers for a registered process who finished waiting

Currently, we never unregister our intents. This means that if we wait(), return from wait (so we're Scheduled/Running), and then get an IRQ for another event, we'll add the process to the schedule queue again, causing an assert.

I believe we should clean up registrations.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.