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

71–80 of 133 posts

Re: Rewrite Linux Kernel in Rust?

#71

Post by martamoreno »

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 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. Even for a browser, Rust is only a band-aid. The amount of logical errors and security holes in something as complex as a modern web-browser is more than enough of an attack surface. No need for a rouge pointer to weird memory.

What is MUCH more viable though is a project to compartmentalize the Linux Kernel into HVMs. I forgot the name but there are efforts to put nearly everything into its own HVM. Which means if the printer driver goes nuts, it can't really do anything to your system except not print anymore. If your graphics driver goes nuts, well then you won't see anything... And so on.

This means, almost no code rewrites and still MUCH higher protection than RUST. Rust does not compartmentalize. If any of your system components is fucked, your whole system is still fucked. That is why it's pointless to rewrite a kernel because of a language. You need to compartmentalize it...

Look at QubesOS for an early user-space effort. Would be nice to have a Qubes-Kernel too.

Re: Rewrite Linux Kernel in Rust?

#72

Post by i336_ »

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're referring to microkernel/nanokernel architectures.

Linus famously shunned Andrew Tanenbaum's MINIX kernel design and argued in favor of a monolithic kernel, where buggy printer drivers live in the same memory space and have the same elevated privileges as the code that manages the kernel's secure crypto key ring.

Linus is also noted in this thread as not being interested in security issues.

I do agree with you about Rust not solving the hardware problem.

Re: Rewrite Linux Kernel in Rust?

#73

Post by wangii »

paulddraper wrote: post #37
polygot wrote: post #10

This is an interesting idea, but probably won't work out because Linus (and other developers) may not want to transition away from the C language (see Linus's comments about not using C++.) I think it would be excellent to see Rust being used, but the implementation of replacing C with Rust could be very complicated, and Rust's benefits may not be directly visible when having to port/rewrite a lot of the components.

And GNU Herd weren't on board with creating a monolithic kernel. So what? It got built.

you mean GNU HURD?

Re: Rewrite Linux Kernel in Rust?

#75

Post by martamoreno »

i336_ wrote: post #72
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're referring to microkernel/nanokernel architectures. Linus famously shunned Andrew Tanenbaum's MINIX kernel design and argued in favor of a monolithic kernel, where buggy printer drivers live in the same memory space and have the same elevated privileges as the code that manages the kernel's secure crypto key ring. Linus is also noted in this thread as not being interested in security issues. I do agree with you…

Yes it also makes sense. Because no matter what you do, it is unlikely that your are able to compartmentalize something so critical and raw as a device driver. If that one is fucked, the reason is likely that your system is already compromised. It was just an example of what WOULD be more viable and effective than rewriting it in Rust.

I still think that QubesOS is taking the right approach. Initially assume hardware & kernel as trusted and make sure that this trust then can not be violated from the outside (TPM, SecureBoot, VMs for each app, etc.). I just wish more people would focus on that promising approach.

Re: Rewrite Linux Kernel in Rust?

#76

Post by i336_ »

Animats wrote: post #51

I'd rather see a rewrite of QNX in Rust, as open source. The QNX kernel isn't very large, but it offers most of POSIX, so you can run programs on it. (L4 is nice, but it does so little that people just use it as a hypervisor to run Linux. This doesn't simplify the problem.) If you rewrite the Linux kernel in Rust, one module at a time, you'll just end up with C written in Rust syntax, with raw pointers all over the p…

QNX is also realtime.

In order to provide realtime guarantees that cover small latencies, you need infrastructure that generates as few instructions as possible. (If you have lots of instructions you can hit targets of a hundreds of microseconds since you can just wait. Start inching toward nanoseconds, though, and the scheduler's own execution will get in the way unless it's crazy compact.)

The reason I mention this is that QNX runs on a variety of embedded devices (http://qnx.symmetry.com.au/ has an interesting list, universal remotes particularly jumped out at me) which are traditionally quite slow.

What's Rust like in terms of generating code that's consistently compact?

Re: Rewrite Linux Kernel in Rust?

#77

Post by i336_ »

martamoreno wrote: post #75
i336_ wrote: post #72

Earlier quoted context omitted.

You're referring to microkernel/nanokernel architectures. Linus famously shunned Andrew Tanenbaum's MINIX kernel design and argued in favor of a monolithic kernel, where buggy printer drivers live in the same memory space and have the same elevated privileges as the code that manages the kernel's secure crypto key ring. Linus is also noted in this thread as not being interested in security issues. I do agree with you…

Yes it also makes sense. Because no matter what you do, it is unlikely that your are able to compartmentalize something so critical and raw as a device driver. If that one is fucked, the reason is likely that your system is already compromised. It was just an example of what WOULD be more viable and effective than rewriting it in Rust. I still think that QubesOS is taking the right approach. Initially assume hardware…

I agree.

Writing in Rust might make the iteration/development process itself a little easier, I'll give it that.

I also like the idea about creating a system that does its best to isolate components and create a trustworthy environment. I'd probably pull the enforcement into the kernel though - not quite SELinux/grsecurity/AppArmor, more a system that completely isolates everything.

Kind of like the direction Linux is going with containerization, but developed that way from the start.

Re: Rewrite Linux Kernel in Rust?

#78

Post by tom_mellior »

AstralStorm wrote: post #48
hyperpape wrote: post #33

Earlier quoted context omitted.

This does raise the question: which languages other than AT&T assembly put the value first?

AT&T syntax puts the operator first, not the value. AT&T is Verb Subject Object. Intel is alien Verb Object Subject. Many kinds of S expressions result in similar code. That would mean Lisp derivatives.

> AT&T syntax puts the operator first, not the value.

If "operator" has any meaning in assembly language, it would have to refer to the opcode. Both variants have the opcode (mov/movl) first.

> AT&T is Verb Subject Object. Intel is alien Verb Object Subject.

Both "move 5 into EAX" and "move into EAX the value 5" are imperatives. Neither of them has a subject, or more precisely, the subject is omitted (https://en.wikipedia.org/wiki/Imperative_mood). In both of these, 5 is an object. "into EAX" is an adverbial phrase or something.

It's true that one sounds more alien than the other when forcibly translated to English. Then again, assembly language is not English, so that's neither here nor there.

Re: Rewrite Linux Kernel in Rust?

#79

Post by fjallidergodur »

kbenson wrote: post #9

Without making any assertions as to the benefits or problems of integrating Rust into the Linux kernel to replace components, I just want to point out it's really cool that you can and that someone has gone through the trouble of documenting how. That's just awesome. Discussion about whether this is a good idea or not, and the problems of doing so, can now commence in earnest, and without the pesky problem of it bein…

The author said:

Thank you very much for your appreciation. In my opinion, such a toy projet would not be of much use if I didn’t document it so others can learn from it or improve on it. :-)

Re: Rewrite Linux Kernel in Rust?

#80

Post by chipaca »

i336_ wrote: post #69
ajross wrote: post #17

Earlier quoted context omitted.

AT&T assembly style significantly predates C++ (and C# by like two decades), and co-evolved with C. And strictly this isn't an assignment, anyway. Assignment is an abstract operation in a programming language. This is a machine instruction[1] for a physical machine, which does exactly one thing. [1] Pause while the peanut gallery points out that in fact there are like ninety six different instructions in x86 called s…

What. When did `mov` get 96 different instructions?

I think it's just a bit of hyperbole. I don't know enough of this to know whether http://c9x.me/x86/html/file_module_x86_id_176.html is complete, but it gives you a sense of it all. (also https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf if you haven't seen it)
Post reply on HN