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

Supporting Linux kernel development in Rust

lwn.net

Post reply on HN
Print view View original

121–130 of 365 posts

Re: Supporting Linux kernel development in Rust

#121

Post by stjohnswarts »

ghostwriter wrote: post #30

I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects , that it isn't. The safety guarantees that Rust provides are neither unique nor complete, and if we discuss the amount of effort necessary for bringing new interfaces like the one this article mentions ("one can define a kmalloc_for_rust() symbol containing an un-inlined version"), we…

How do you know unless you try? I don't know why people are so against it. If you want to see vitriol see any discussion of rust on the now impotent slashdot community. If Linus is okay with it, I'm okay with it. He knows a lot more about the kernel than me and probably 99.99999% of of the people on the planet. I'm sure there are some awesome Einstein IQ people that know it even better than Linux, but I'll probably never meet them.

Re: Supporting Linux kernel development in Rust

#122

Post by ghostwriter »

geofft wrote: post #106
ghostwriter wrote: post #68

Earlier quoted context omitted.

It's not only inclusion of the headers. ATS compiles to C, and it can inline C without FFI. The benefit that you receive is the ability to introduce gradual automated proofs around unchanged stable interfaces that are known to be safe. You start with inlining everything but the small core that is proven to be safe. Then you can iterate indefinitely at the desired pace to bring new layers of formally verified API in p…

> it can inline C without FFI I'm not sure what you mean by "FFI" (I would apply the term "FFI" to the way ATS interoperates with C, too), but you can certainly get cross-language LTO between C and Rust, since they both compile to LLVM IR. > you can iterate indefinitely at the desired pace to bring new layers of formally verified API in places of previously unverified C calls without breaking backward compatibility a…

I meant not having to think about wrapping/boxing/unboxing, as they have exactly the same native data representation, so it's slightly different than LTO. But mine using "FFI" there was probably too vague and frivolous, I agree.

> You can do this in Rust, too.

not always within boundaries of safe Rust though (assuming each iteration is allowed to brings zero unsafe/unverified code), which undermines the initial safety argument.

Re: Supporting Linux kernel development in Rust

#123

Post by robocat »

JoshTriplett wrote: post #32
danudey wrote: post #25

Earlier quoted context omitted.

The Linux kernel would only compile with GCC for... decades? I think? So it's not really a new thing. It would be really nice if the kernel did have first-class support for LLVM and Clang directly (rather than having to set a bunch of environment variables to set the compiler, the linker to use with that compiler, various variables, etc. That said, it would certainly be uncomfortable to move from "it compiles with Cl…

Originally, we thought that Linux maintainers were asking us to only support kernels compiled with Clang, because they didn't want to support code built with two different compilers. However, in the session, Greg Kroah-Hartman specifically said that if it works to build Rust code with the LLVM-based rustc and C code with GCC and link the two together, and there aren't any problems in practice, then that's perfectly f…

Article discussing LTO (Link Time Optimizations, used by Google Pixel) and PGO (Profile Guided Optimizations): https://www.phoronix.com/scan.php?page=news_item&px=Microsof...

Re: Supporting Linux kernel development in Rust

#124

Post by hu3 »

stjohnswarts wrote: post #121
ghostwriter wrote: post #30

I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects , that it isn't. The safety guarantees that Rust provides are neither unique nor complete, and if we discuss the amount of effort necessary for bringing new interfaces like the one this article mentions ("one can define a kmalloc_for_rust() symbol containing an un-inlined version"), we…

How do you know unless you try? I don't know why people are so against it. If you want to see vitriol see any discussion of rust on the now impotent slashdot community. If Linus is okay with it, I'm okay with it. He knows a lot more about the kernel than me and probably 99.99999% of of the people on the planet. I'm sure there are some awesome Einstein IQ people that know it even better than Linux, but I'll probably n…

> I don't know why people are so against it.

There's an extremely high cost to introduce and maintain another language in a stack such as the Linux kernel. Everyone involved would be permanently impacted regardless of their opinion on the matter. It's not just a flag you can toggle.

Otherwise Rust community would have already forked the Linux kernel instead of bugging their maintainers to RIIR.

On top of that Rust compilation is very costly. It would render some devices that currently can compile the kernel unable to do so.

Last I checked Rust fails to compile itself with 4GB of memory. Here's another user commenting about it: https://news.ycombinator.com/item?id=23059869

Re: Supporting Linux kernel development in Rust

#126

Post by einpoklum »

bsder wrote: post #112
ghostwriter wrote: post #81

Earlier quoted context omitted.

> It's also not limited to Rust, it's about providing support for multiple other languages that could be beneficial in those locations But what are these benefits that other languages bring on the table? From the article it appears that proponents of the new toolchain mention memory-safety as the primary concern: > They focused on security concerns, citing work showing that around two-thirds of the kernel vulnerabili…

> So the natural follow-up question to that concern, it seems to me, would be whether there's something in the existing C/GCC toolchain (or around it) that can resolve the raised concerns without adopting a whole new toolchain (Rust/LLVM) The answer to this question appears to be: no. Memory errors sit somewhere around 2/3 to 3/4 of errors irrespective of codebase when C is involved (this has been consistent in thing…

> C++ hasn't seemed to have changed that, either.

C++ is not like C. Putting some C++ objects in a C codebase would, indeed, not change it much, but if you write in modern C++, some memory errors will literally disappear, and some become less likely.

Caveat: This is based on language mechanics, standard library facilities and recommended idioms; of course people can write unsafe C++ if they want to.

Re: Supporting Linux kernel development in Rust

#127

Post by dang »

ghostwriter wrote: post #30

I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects , that it isn't. The safety guarantees that Rust provides are neither unique nor complete, and if we discuss the amount of effort necessary for bringing new interfaces like the one this article mentions ("one can define a kmalloc_for_rust() symbol containing an un-inlined version"), we…

Please don't be repetitive in HN comments, though. Repetition is the enemy of curiosity and curiosity is the core value here.

https://news.ycombinator.com/newsguidelines.html

Re: Supporting Linux kernel development in Rust

#128

Post by ghostwriter »

simias wrote: post #108
ghostwriter wrote: post #30

I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects , that it isn't. The safety guarantees that Rust provides are neither unique nor complete, and if we discuss the amount of effort necessary for bringing new interfaces like the one this article mentions ("one can define a kmalloc_for_rust() symbol containing an un-inlined version"), we…

The Linux kernel is fairly modular, I could definitely imagine rewriting subsystems by subsystems with fairly good ergonomics and safety. Like rewrite serial_core.c in Rust and then let people write serial drivers in Rust. Then the SPI code. Then the I2C. Then USB etc... Easier said than done of course, and definitely a huge effort especially for such a huge project as the Linux kernel, but there's also a significant…

> Also "the safety guarantees that Rust provides are neither unique nor complete", while technically true, is also borderline FUD-y. At least you should expand on what you have in mind here, because I doubt that there exists a programing language that deals with low level hardware configuration that could ever provide "complete guarantees" about anything.

I meant inability to implement within the boundaries of safe Rust certain data structures and algorithms that ATS can prove to be safe. To name a few: stack-allocated closures, and safe pointer arithmetic programming [1]. For instance, ring buffers in Rust use "unsafe" and at some point there was a logical CVE in vec_deque that broke one invariant of the unsafe block [2]. Safe implementation of the ring buffer in ATS could be found in [1]

[1] http://www.ats-lang.org/MYDATA/SPPSV-padl05.pdf

[2] https://gts3.org/2019/cve-2018-1000657.html

Re: Supporting Linux kernel development in Rust

#129

Post by ansible »

JoshTriplett wrote: post #29
puzzledobserver wrote: post #9

One of the challenges to building an entirely new kernel is the vast amount of hardware support in the form of drivers and the features the existing kernel exports to userland in the form of syscalls. Would it be possible for a hypothetical new kernel, presumably written in Rust, to run an existing kernel such as Linux in a VM, just to tap into its drivers and emulate its syscalls? As more drivers are ported to the b…

The point of this LPC session was how to incrementally introduce Rust in the existing Linux kernel, with all its existing drivers and syscalls and similar. A rewrite would indeed be a daunting and problematic proposition. There are kernels written in Rust, such as Redox, but those are separate projects, and that's not what this conference session or article are talking about. Standing reminder: the Rust project is no…

> Standing reminder: the Rust project is not a fan of rabid Rust over-evangelism (e.g. "Rewrite It In Rust", "Rust Evangelism Strike Force"), and sees it as damaging and unhelpful.

Agreed. If you want to rewrite everything in Rust, then please help out with a project such as Redox where the goal is indeed to write everything in Rust. But don't bother people by talking about that goal, just write some code!

Re: Supporting Linux kernel development in Rust

#130

Post by AlphaSite »

puzzledobserver wrote: post #9

One of the challenges to building an entirely new kernel is the vast amount of hardware support in the form of drivers and the features the existing kernel exports to userland in the form of syscalls. Would it be possible for a hypothetical new kernel, presumably written in Rust, to run an existing kernel such as Linux in a VM, just to tap into its drivers and emulate its syscalls? As more drivers are ported to the b…

ESX once ran this way, it had native drivers and Linux drivers, where it would run Linux as a vm and have it handle drivers for unsupported hardware. theres some more documentation on Wikipedia[1], it later switched to using vmklinux as a shim for those drivers.

[1] https://en.wikipedia.org/wiki/VMware_ESXi#Architecture

Post reply on HN