What is “Rust OS”? This is a more in-depth summary/post about the slides for my research project, Regos-2000. These notes are from the talk I gave at the BURE research symposium in August 2023. Each numbered heading corresponds to a slide number.
My name is Jackie, I worked with professor Robbert van Renesse this summer. The title of my talk is Regos-2000: crossing programming language boundaries. I'll be explaining what regos and crossing boundaries mean later.
So the C programming language is typically used for writing low level software, what we're interested is operating systems kernels.
I did a quick Google search, seems like all the OS kernels you know and love, Mac, Windows, Linux, it's all written in C. And this is just the kernel, so the basic platform your computer needs to run applications on, this does not include the GUIs or windows or xwindow or whatever else.
C's a great programming language, it's fast and relatively simple and most importantly predictable, due to the lack of a garbage collector.
The garbage collector is the runtime system that cleans up dynamic memory allocation, so for example if you were to create a new arraylist in say java, unlike in C where you would have to free that dynamically sized array, in java the garbage collector will take care of reclaiming that memory for you.
This is not ideal for writing low level code, one because of the overhead and two for control.
But all this control that C offers has its downsides, you could accidentally free some memory too early and forget that you freed it, or forget the free the memory in the first place, you can have data races when sharing memory.
Here I have some statistics about the problem with manual memory management.
Even the most seasoned programmers make these mistakes, and these statistics are from within the last decade, so it's still a recurring problem.
These percentages are attributed to the the number of security vulnerabilities whose root cause is from memory unsafety.
We can see almost 50% of Chrome's security vulnerabilites come from memory unsafety, almost 90% in mac, 80% of 0 day exploits, these are sec vulnerabilities that are uncovered while they are already used to attack some system where the developers have had zero days to fix them. This last one is a use after free static analysis, so dereferencing memory that's already been freed. We can see that there are hundreds of cases detected.
So memory unsafety is a big problem.
So the big question is can we get the control and predictability that C offers, without introducing memory unsafety bugs.
In the Linux community there has been a need for a while to have a language level tool to keep track of memory. A big problem with any new tool is that we don't to be rewriting millions of lines of code from an existing applications for compatibility with this tool. And we also want this tool to be accessible.