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

131–140 of 365 posts

Re: Supporting Linux kernel development in Rust

#131

Post by nullc »

JoshTriplett wrote: post #51
joshuawarner32 wrote: post #46

Earlier quoted context omitted.

I’m glad that there other efforts for memory-safety going on concurrently, and we as a software community should absolutely continue to invest in those. I also agree that rust is not suited for all circumstances that people try to use it in - but I would contend that the set of situations where rust is absolutely the right choice is non-empty. I say this as part of a ~20 person team, rewriting business-critical softw…

It's certainly not just about safety. It's about the combination of safety, expressiveness, productivity, and various other factors.

Can someone cite a peer reviewed study that supports the belief that rust increases safety or productivity in actual use?

Re: Supporting Linux kernel development in Rust

#132

Post by ghostwriter »

dbaupp wrote: post #100
ghostwriter wrote: post #87

Earlier quoted context omitted.

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.

That helps with the "library availability" sub-point specifically, yes. However, there's a more than that when evaluating a language, as suggested by my comment above. In any case, if one is discussing modern and safe languages, there's a dramatic difference between using a C library and using a library native to the language. Even ignoring safety, the ergonomics/developer experience is dramatically different and the…

> (Formally verified is shifting the goal posts here: the bar is just "has a native library".)

It is, but it is for a good reason - ATS formally verifies your safe functions, so you only need to implement your proof once and make a compiler agree with you, and then you can save on a community-driven code-review process. Rust, on the other hand, provides safety guarantees only for a subset of safe guarantees that ATS provides. Pointer manipulations have to reside in "unsafe" blocks, and that leads to CVEs - https://gts3.org/2019/cve-2018-1000657.html

Re: Supporting Linux kernel development in Rust

#133

Post by ghostwriter »

outworlder wrote: post #78
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 safety guarantees that Rust provides are neither unique nor complete That sounds like "LEDs shouldn't be used for traffic lights because they don't melt snow", while ignoring all the benefits. Just add a heater where it is required. Rust does add benefits. Are these worth the extra effort? It seems that some people think it's worth it.

The question is more specific - does it add more benefit to the existing well-established C codebases, compared to other tooling particularly aiming at helping existing C codebases.

Re: Supporting Linux kernel development in Rust

#134

Post by ghostwriter »

darksaints wrote: post #113
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…

Reading through your various replies to comments, it seems your argument boils down to the FFI issue, and I find that a little bizarre. Sure, ATS can inline library calls due to the lack of an FFI, and maybe it has a cleaner interface to those libraries, but now you've introduced a completely different set of problems: now you have to tell the compiler how to prove your code. In my experience, learning the fundamenta…

Hmm, I think my point is less about "native" FFI and more about safety guarantees and compatibility. Not every algorithm is portable to safe Rust without loosing on runtime/performance characteristics of the code, and falling back to unsafe Rust for that matter undermines the initial "rust is memory-safe" argument. C codebases are heavily invested in pointer-based algorithms and optimisations. ATS is able to verify them, Rust isn't.

Re: Supporting Linux kernel development in Rust

#135

Post by ghostwriter »

Athas wrote: post #73
gameswithgo wrote: post #65

Earlier quoted context omitted.

>The safety guarantees that Rust provides are neither unique nor complete, Well no language can ever have "complete" safety guarantees. But I would like to know what other languages offer the same set of guarantees without GC overhead. This would include: * the usual memory safety * no nulls * no undefined behavior * no data races Does ATS guarantee those things?

Yes, ATS can guarantee all those things and more. In particular, ATS allows you to write "unsafe" code, which you then prove safe with a mechanically verified proof. This is in contrast to unsafe Rust, which depends on programmer discipline, and has no (intra-language) mechanism for verification beyond the basic type system. You could say that Rust is all-or-nothing, while ATS allows gradual verification, as well as…

> It's just that most people are not willing or able to pay the very high price in ergonomics.

Hopefully it will get better in ATS3 - https://github.com/githwxi/ATS-Xanadu#project-description

Re: Supporting Linux kernel development in Rust

#136

Post by jasonhansel »

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…

L4Linux was (is?) a similar project: https://l4linux.org/overview.shtml

The idea of that project was to turn Linux into a user mode application run by a microkernel; rewriting that microkernel in Rust would essentially give you what you're suggesting.

Re: Supporting Linux kernel development in Rust

#137

Post by jasonhansel »

I'm concerned about the gradual move from GCC to LLVM. The lack of copyleft protections on LLVM means that it's much more dependent on corporate sponsorship, and means that there's a risk that major improvements to LLVM compilers will only become available as proprietary products.

People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.

Re: Supporting Linux kernel development in Rust

#138

Post by sanxiyn »

msla wrote: post #97

What kind of performance hit is rewriting part of the kernel in Rust going to entail when it comes to compiling the kernel? How many platforms will cease to be able to compile their own kernels? The article says there will be some, but doesn't give numbers. More worryingly, the article also says that only some platforms will be "Rusted" in this manner, splitting the codebase into "mainline Rust" and "obscure platform…

Architectures supported by Linux kernel but not supported by Rust are tracked at https://github.com/fishinabarrel/linux-kernel-module-rust/is.... It currently lists 14 architecutres (as opposed to 10 supported architectures), so it's less than half.

Re: Supporting Linux kernel development in Rust

#139

Post by dnautics »

jasonhansel wrote: post #137

I'm concerned about the gradual move from GCC to LLVM. The lack of copyleft protections on LLVM means that it's much more dependent on corporate sponsorship, and means that there's a risk that major improvements to LLVM compilers will only become available as proprietary products. People underestimate the role of copyleft licenses in preserving long-running FOSS products like GCC, Linux, etc.

Can you give an example of a non-copyleft open source product where the major improvement is proprietary?

Re: Supporting Linux kernel development in Rust

#140

Post by shock »

nullc wrote: post #131
JoshTriplett wrote: post #51

Earlier quoted context omitted.

It's certainly not just about safety. It's about the combination of safety, expressiveness, productivity, and various other factors.

Can someone cite a peer reviewed study that supports the belief that rust increases safety or productivity in actual use?

> rust increases safety or productivity in actual use?

compared to what?

Post reply on HN