Ask HN: When Will Rust-for-Linux Be Completed?
Is there a roadmap?
19 comments
What exactly do you mean by that?
The first kernel with Rust bits will be 6.1, probably going to be released on monday.
The first kernel with Rust bits will be 6.1, probably going to be released on monday.
Sorry, I meant when will Rust for Linux be completed? Meaning, when all the C code will be replaced with Rust? I will change the title.
Go ahead and rewrite 30+ million lines of C code in Rust, LMAO.
It's not going to happen, Rust support is being added for new code, not specifically to rewrite the kernel.
New kernels are being built because Linux security is so bad, I wouldn't be so surprised.
I mean, Redox is cool but it's not going to replace real, full-fat kernels. Linux is just as secure (if not more secure) than Apple's XNU kernel, or Microsoft's NT kernel, in that respect.
The Linux kernel is very bad in terms of security. For example, Linux namespaces had several critical CVE's, and much more.
So? Every other kernel ever designed also has critical kernel-mode vulnerabilities. The difference is, on Linux, they get fixed.
That's a wrong fact. Every critical vuln gets fixed as fast as possible in any kernel. Linux actually sometimes takes their time.
The Linux kernel has the best security you can get with a C based monolithic kernel in production. Vulnerabilities often get patched hours to at worst a few days after they become disclosed; Which is faster than NT & XNU which often
can take from weeks to months, and even a year or more in some past cases; which makes sense because they have limited dev power while Linux is the largest collaborative project on the planet.
The new kernels simply aren't production ready except for some niche areas, while Linux is used anywhere from PC, Servers, Embedded Devices, Supercomputers, The National Space Station, to even NASA's Mars Helicopter.
The largest security problem the Linux kernel faces to date is memory unsafety mistakes, and is where Rust comes in. Rust's approach to memory safety is from what I can tell a match made in heaven for Linux kernel development and is very likely going to greatly reduce the amount of memory unsafety bugs introduced into the production code, but time will tell.
On the flip Rust in Android has had a great impact on reducing memory unsafety bugs; which is very good news and gives us measurable data on the potential impact of Rust in Linux.
The new kernels simply aren't production ready except for some niche areas, while Linux is used anywhere from PC, Servers, Embedded Devices, Supercomputers, The National Space Station, to even NASA's Mars Helicopter.
The largest security problem the Linux kernel faces to date is memory unsafety mistakes, and is where Rust comes in. Rust's approach to memory safety is from what I can tell a match made in heaven for Linux kernel development and is very likely going to greatly reduce the amount of memory unsafety bugs introduced into the production code, but time will tell.
On the flip Rust in Android has had a great impact on reducing memory unsafety bugs; which is very good news and gives us measurable data on the potential impact of Rust in Linux.
Thanks for the info. I must say that actually the kernel isn't the problem, but how distros use the kernel by providing bloat and other.
Critical Linux vulnerabilities often get livepatched in a number of hours, the NT kernel and XNU kernel normally takes months to roll out patches. You don't seem to know what you're talking about here, so I'm not going to provoke you any further.
[deleted]
That's not the stated goal of the Rust-for-Linux project.
Huh. So it's only for adding support for the Rust language? Is it about adding support for running kernel syscalls and other in rust?
The goal of the Rust-for-Linux project is to make it possible to implement kernel components in Rust and having Rust be an accepted and supported choice to do so inside the upstream kernel - and for people to use that support of course. It's expected that this is primarily going to be used for driver development, at least at first, since it's quite useful there, it is something where new wholesale components are being written, and the limited compiler/platform support is acceptable. Replacing existing components, especially any core parts of the kernel, is not part of any outlined plan or roadmap.
There are no current initiatives to start porting portions of the kernel into Rust wholesale. The recent Rust support was merely giving Kernel developers the option to use Rust in situations where memory safety might be preferred.
Isn't memory safety needed in all cases?
Not really. There are a lot of things we can do fairly reliably without guaranteed memory safety, and the danger-zones that do exist are pretty clearly mapped and well-known to kernel devs. There are also a lot of things that do need memory safety, but the architecture is usually designed to minimize UB and keep things simple as possible. If you manage to segfault a modern Linux kernel, you're probably using extremely unsupported hardware.
Rewriting Linux in Rust is veritably impossible anyways. It would require re-reviewing over 3 decades of kernel contributions and locking down high-quality 1:1 replications of the previous code. It's just not going to happen, at least not while the standards for merging to the kernel is so high.
Rewriting Linux in Rust is veritably impossible anyways. It would require re-reviewing over 3 decades of kernel contributions and locking down high-quality 1:1 replications of the previous code. It's just not going to happen, at least not while the standards for merging to the kernel is so high.
The current plans only go so far as to supporting in-kernel device drivers in rust. It will be quite a while if ever before core parts of the kernel are written in rust.