Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewrite Linux Kernel in Rust?

dominuscarnufex.github.io

Post reply on HN
Print view View original

101–110 of 133 posts

Re: Rewrite Linux Kernel in Rust?

#101

Post by gorthol »

devdoomari wrote: post #61
Jach wrote: post #52

Earlier quoted context omitted.

Nim or Rust might be appropriate depending on the project. To me the idea of replacing C with either of them comes down to a value-sell of how much you value Rust's safety guarantees and whether you're willing to make the investment of learning to use it or if you're just going to wrap everything in unsafe{}. Considering you're talking to C programmers, I don't think they value that safety very much. If they did, at…

pardon my ignorance, but wasn't "safe-and-performant" impossible before rust? Isn't choosing a GC-language some trading off performance for safety?

I think it was "safe and performant without a GC" because both Nim and D have C++ level performance while being memory safe as any GCd language is.

Re: Rewrite Linux Kernel in Rust?

#102

Post by Retra »

youdontknowtho wrote: post #85

I guess one of the things that always comes to mind when someone brings up "Rust all the things" is that it assumes that anything that can be expressed in C can be expressed in Rust with the safety features enabled . Rust wouldn't have a mechanism to do unsafe code otherwise, right? I think it might be more complicated than we might think initially. I personally think that someone should probably spend some more time…

Safe rust clearly cannot express everything that can be expressed in C. It cannot even express everything that is safe in general. But "the safety features of Rust" includes drawing a barrier between the safe parts of your code and the unsafe parts. There is significant value in that compartmentalization. Moreover, you are assuming that things written unsafely in C should be written identically in rust, when there very well could be more idiomatic, modern ways to do the same thing without any unsafety at all.

Re: Rewrite Linux Kernel in Rust?

#103

Post by moomin »

bonzini wrote: post #68
devdoomari wrote: post #61

Earlier quoted context omitted.

pardon my ignorance, but wasn't "safe-and-performant" impossible before rust? Isn't choosing a GC-language some trading off performance for safety?

There were other attempts to bridge safety and performance. C++11 already gets​ pretty close to that, but Microsoft's M# was used to write a research OS and is probably the closest.

C++, though, only works if you follow a bunch of coding guidelines (that I can tell you for free the last C++ team I worked on didn't) and don't interface with any library APIs that don't follow those guidelines.

Don't get me wrong, C++ is coming on by leaps and bounds, but if you want to get to safe and performant without GC, it's not the place you should be starting. (Equally, I'm not saying Rust solves all the world's problems. Just that it's a better place to start.)

Re: Rewrite Linux Kernel in Rust?

#104

Post by nickpsecurity »

geezerjay wrote: post #65
nickpsecurity wrote: post #47

Earlier quoted context omitted.

This is a good argument if a massive amount of effort was piled into this with lots of refactoring on top of it. Meanwhile, it doesn't have a snowball's chance in hell of accomplishing anything.

> Meanwhile, it doesn't have a snowball's chance in hell of accomplishing anything. That's only true if you believe that the only possible accomplishment is to become the #1 kernel in the world. Meanwhile, it's a very interesting project and it's a clear proof of technical proficiency. There are not many people in the world who can claim that they've written a kernel, let alone one in a cutting-edge programming langu…

"Meanwhile, it's a very interesting project"

I was responding to a comment about doing the whole Linux kernel, not the original project. The original project makes sense. You gave another, good reason for that.

"Meanwhile, criticizing other people's projects does nothing to advance your career."

Professors grading things, peer review of research, managers reviewing performance, consumer organizations reviewing products... there's a lot of reasons that statement is wrong. I try to critique with an alternative solution presented and citations for both statements where possible. In the Linux case, I've often recommended tech at hardware and compiler level that automatically makes C code safe some of which have been used on FreeBSD and Linux. Alternatively, running it as a VM on top of a secure microkernel with security-critical apps running outside the VM.

Re: Rewrite Linux Kernel in Rust?

#105

Post by nickpsecurity »

delhanty wrote: post #60
nickpsecurity wrote: post #47

Earlier quoted context omitted.

This is a good argument if a massive amount of effort was piled into this with lots of refactoring on top of it. Meanwhile, it doesn't have a snowball's chance in hell of accomplishing anything.

The key for such a project being successful would be to set expectations low in defining what success was. Something like "a proof of concept of an experiment to rewrite small amounts of the Linux kernel in Rust". One would fork Linux on GitHub, name it something other than Linux, and just have the existing branches track Linux. Linus has stated that he isn't particularly interested in security bugs. Other people tak…

"One would fork Linux on GitHub, name it something other than Linux, and just have the existing branches track Linux"

That's already hard given how many commits go into Linux. One must always remember it's not just some volunteer project: most of the commits are by paid programmers working at companies. That's where the labor comes from. You'd need a lot of volunteers to keep up with the paid programmers. Even Linux itself couldn't achieve that. Hence, all the paid programmers working on it.

"might be to take the lessons learned to create a conservative set of Rust inspired extensions to C without all the hoariness of C++."

Now you're thinking on the right track. That sort of thing has been done multiple times at the compiler level where they automagically make C safe with a performance hit. Several teams did it at CPU level. These projects have been used on FreeBSD mostly but also Linux. The strongest one so far is CheriBSD on CHERI processor.

Alternatively, for a safer C that you're manually using, what you describe has already been designed and actually inspired Rust's safety model:

https://en.wikipedia.org/wiki/Cyclone_(programming_language)

It could be revived and improved if people wanted. It got nowhere with C programmers, though, in the past.

Re: Rewrite Linux Kernel in Rust?

#106

Post by pavement »

saghm wrote: post #45
im_down_w_otp wrote: post #4

Pretty cool. I decided to take a similar path in trying to improve/ensafen parts of the BEAM VM by finding small chunks I could rewrite in Rust from C. Most of the headache was build toolchain integration stuff. I did manage to get a few simple things slotted in that appear to work transparently, which made me hopeful for future more complicated things to play with like new process mailbox implementations, etc. Anywa…

OT: I really like the word "ensafen", and I'm totally going to borrow it for future use

It's a perfectly cromulent word, and embiggens every sentence and phrase that includes it.

Re: Rewrite Linux Kernel in Rust?

#107

Post by im_down_w_otp »

youdontknowtho wrote: post #87
im_down_w_otp wrote: post #53

Earlier quoted context omitted.

Nope, not the reason. My "go-to" language when prototyping most things is still Erlang. Erlang is by far my favorite language and environment to use, and for a whole slew of things I'd still grab it for production projects/products. I moved into the world of autonomous vehicle runtime software, and tools closer to the metal with deterministic timing characteristics are a requirement.

What is it about Rust that helps with the deterministic timing thing you mentioned? Just not having a GC? Do you still use C or C++?

No GC, optional runtime (no_std), etc.

Yep, still use C and C++.

Re: Rewrite Linux Kernel in Rust?

#108

Post by kqr »

martamoreno wrote: post #71

It's a fun idea and many people have had it first thing when they heard of Rust... So why did no one do it? Quite simply: No one is going to rewrite the Linux Kernel in Rust. It is far too big and also you are not solving any real issues either. Rust only protects you from a small fraction of errors and while for an application like a browser, this can be a big gain, I would argue that it is negligible for a kernel i…

> you are not solving any real issues either. Rust only protects you from a small fraction of errors and while for an application like a browser, this can be a big gain, I would argue that it is negligible for a kernel in general. Reasons being that all the device IO, component interaction, privilege escalations, logical errors, hardware errors, firmware errors/bugs all can NOT be addressed by rust.

Would something like Ada SPARK be more helpful here? And what critical parts of that is Rust missing?

Re: Rewrite Linux Kernel in Rust?

#109

Post by Jach »

devdoomari wrote: post #61
Jach wrote: post #52

Earlier quoted context omitted.

Nim or Rust might be appropriate depending on the project. To me the idea of replacing C with either of them comes down to a value-sell of how much you value Rust's safety guarantees and whether you're willing to make the investment of learning to use it or if you're just going to wrap everything in unsafe{}. Considering you're talking to C programmers, I don't think they value that safety very much. If they did, at…

pardon my ignorance, but wasn't "safe-and-performant" impossible before rust? Isn't choosing a GC-language some trading off performance for safety?

It's a common misconception that GC languages must be slower than languages without one. Where that misconception probably comes from is that it's pretty easy to write performant code in C, and hard to write terribly slow code, whereas in languages with GC in some instances you can do as good or better but it's often harder. These days if you're comparing Java and C++, it's not unusual for the Java code to be faster. The bigger tradeoff for GC is more in the loss of determinism, some applications (like games) can't tolerate a random stop-the-world collection for n ms. This can be mitigated by pauseless/stoppable/real-time-guarantees GC implementations though so if your language lets you swap the GC you have options around this. (For something like a game, naive malloc/free aren't enough either. You're going to have to manage your memory intelligently regardless of if you have a GC or not.)

As for Nim all I can say is run some benchmarks on C, Rust, and Nim. Compare the ease of implementation. Compare the relative safeties beyond memory ownership safety. Nim does very well.

Post reply on HN