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

81–90 of 365 posts

Re: Supporting Linux kernel development in Rust

#81

Post by ghostwriter »

kbenson wrote: post #61
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…

> 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. That's not what this is about, so even though you aren't tired of posting this, I'm not sure it's warranted. This is about the kernel supporting other languages in select places where it makes sense, such as kernel modules, where there's already an API in place to con…

> 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 vulnerabilities that were assigned CVEs in both Android and Ubuntu stem from memory-safety issues. Rust, in principle, can completely avoid this error class via safer APIs enabled by its type system and borrow checker.

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) and without having to extend the existing interface with language-specific suffixes like "kmalloc_for_rust".

Re: Supporting Linux kernel development in Rust

#82

Post by outworlder »

rumanator wrote: post #63
stmw wrote: post #48

Earlier quoted context omitted.

ATS certainly looks interestinb, but it's an academic language (of which there are many) that most people probably haven't heard of... At some point, the momentum of a new programming language is just as important -- in practical terms -- as its formal attributes and qualities.

Your centering your criticism of ATS on popularity. Does an investment on PR trumps technical merit?

> Does an investment on PR trumps technical merit?

If PR == popularity, yes.

Otherwise we would all be writing our stuff in Haskell, Lisp, Elm, F# and similar, and Algol-derived languages would be a footnote at this point.

Re: Supporting Linux kernel development in Rust

#83

Post by johncolanduoni »

ghostwriter wrote: post #68
johncolanduoni wrote: post #52

Earlier quoted context omitted.

How does ATS provide safety guarantees without additional semantic information about the C code it’s linking to? If it does require that, then you’re in the same boat as Rust: your choices are trivial interoperation with no safety at the interfaces or encoding the semantics of the C interface in the new language. The only difference I can think of is built in ability to inline C from headers (based on your comment ab…

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…

This may need fewer code changes (if the code in question is correct and the interfaces can possible be implemented in a safe way, that is) but it still requires developers to write proofs in a dependent type theory. I’ve only looked at ATS briefly, but I’m familiar with a lot of the other languages in the space (Idris, Fstar, etc.). Are ATS’s proof tactics drastically more productive/brief than those (F* in particular, which has great aliasing reasoning)? If not I think you’re radically overestimating the approachability of this route compared to Rust.

Re: Supporting Linux kernel development in Rust

#84

Post by JoshTriplett »

boogies wrote: post #70
JoshTriplett wrote: post #40

Earlier quoted context omitted.

My comment was entirely based on the second link. Direct quote from that: > Linux kernel forcing adaption of DRM, including HDCP. (Which linked to a patch adding driver support for handling HDCP, with absolutely no possibility of it somehow being forced.) Regarding the quote from that interview: sure, and there's also no guarantee that the Linux kernel won't drop support for every architecture except SPARC, except of…

I don’t know about Linux, but Mozilla has mandated many things that I would have hoped it never would have, like XUL depreciation, and especially added many anti-features to their largest product, deciding each was not their hill to die on https://news.ycombinator.com/item?id=24124954 . I left Firefox and have never regretted it. The Hyperbola devs did the same, and I will be happy to try their OS and support them fi…

> like XUL depreciation

There were specific reasons for that: https://yoric.github.io/post/why-did-mozilla-remove-xul-addo...

Re: Supporting Linux kernel development in Rust

#85

Post by _8j50 »

steveklabnik wrote: post #58
_8j50 wrote: post #36

Earlier quoted context omitted.

They can call it something else entirely. Rusty? Brown? Who cares so long as it is compatible with rustc

If it is compatible with rustc, then we would probably approve a request to use the trademark.

They don't want to have to ask.

Re: Supporting Linux kernel development in Rust

#86

Post by steveklabnik »

_8j50 wrote: post #85
steveklabnik wrote: post #58

Earlier quoted context omitted.

If it is compatible with rustc, then we would probably approve a request to use the trademark.

They don't want to have to ask.

Yes, I understand that. Just trying to make it clear that the issue is with that itself, not on our side.

Re: Supporting Linux kernel development in Rust

#87

Post by ghostwriter »

dbaupp wrote: post #76
rumanator wrote: post #63

Earlier quoted context omitted.

Your centering your criticism of ATS on popularity. Does an investment on PR trumps technical merit?

Popularity and momentum translate into (and are proxies for) important things like: library availability, long-term maintenance and support, more edge cases are explored (so less “research”, breaking new ground and bugs when going off the beaten track), tooling and even availability of teaching material like documentation and tutorials.

In case of ATS, any C library can be treated as a "unsafe-marked" ATS library, so there's no problem with library support, the problem is with their formal verification. And Rust libraries regularly suffer from the same lack of formally-verified and proven-to-be-safe APIs.

Re: Supporting Linux kernel development in Rust

#88

Post by alex7o »

ColanR wrote: post #27
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…

I was thinking about something similar recently - if the hardware drivers could somehow be abstracted from the rest of the linux kernel (as if...), then suddenly a ton of experimental kernels could have widespread hardware availability. It would probably shake up the OS ecosystem to no small degree, but I imagine the fresh ideas that could be experimented with by non-experts would be hugely beneficial. Isn't that the…

This exists and is called rumpkerbels if I remember correctly.

Re: Supporting Linux kernel development in Rust

#90

Post by geofft »

The_rationalist wrote: post #47

It's not about safety, if that was the real argument we should start with obvious improvements like checked C https://github.com/microsoft/checkedc The C++ lifetime checker or Cyclone

Checked C addresses a small number of memory safety problems - it addresses bounds checking / buffer overflows, but not use-after-frees, double frees, data races / insufficient locking, and several other things that fall into the general category of "memory safety," nor more general "safety" things like type confusion.

The kernel is not written in C++ and is unlikely to use C++, for many reasons - Rust is a more natural C-but-better for the kernel than C is.

Cyclone hasn't been maintained for over a decade; it was a research language, and it largely served its purpose as a research language in inspiring production-supported languages like Rust.

Post reply on HN