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

181–190 of 365 posts

Re: Supporting Linux kernel development in Rust

#181

Post by woodruffw »

sroussey wrote: post #167
woodruffw wrote: post #162

Earlier quoted context omitted.

> 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. As someone who works within LLVM professionally, I don't think this is particularly likely -- compilers are massive and complicated beas…

But Intel put proprietary work in ICC and their math libs, so there is something on periphery that’s going to keep the worry alive even if it doesn’t have a base.

Well, to be clear, both ICC and MKL are fully proprietary. They do indeed justify the worry, but they're not in the same "open source but may be susceptible to proprietary creep" category.

Re: Supporting Linux kernel development in Rust

#182

Post by Google234 »

higerordermap wrote: post #178
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.

I am even more concerned about LLVM monoculture. LLVM is just a proprietary-able version of GCC. And thus compiler authors mostly focus on benchmarks while not caring about other metrics such as compilation speed, correctness and codebase quality / ease of contribution. There appears to be some tribal knowledge requirement to add a new target. With all the hype and apple funding LLVM gets, it could have been better.

I all see are a bunch of baseless accusations.

Re: Supporting Linux kernel development in Rust

#183

Post by yzmtf2008 »

higerordermap wrote: post #178
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.

I am even more concerned about LLVM monoculture. LLVM is just a proprietary-able version of GCC. And thus compiler authors mostly focus on benchmarks while not caring about other metrics such as compilation speed, correctness and codebase quality / ease of contribution. There appears to be some tribal knowledge requirement to add a new target. With all the hype and apple funding LLVM gets, it could have been better.

I wouldn't say GCC has an edge on "codebase quality / ease of contribution". Doesn't RMS actively pushes against such metrics? https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html

Re: Supporting Linux kernel development in Rust

#184

Post by Manishearth »

woodruffw wrote: post #162
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.

> 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. As someone who works within LLVM professionally, I don't think this is particularly likely -- compilers are massive and complicated beas…

I agree, as someone who works on rustc I think it's a significant endeavor to maintain a substantial fork of either Rust or LLVM.

(Rust does maintain a fork of LLVM, but it's just a couple minor patches that typically get upstreamed eventually)

Re: Supporting Linux kernel development in Rust

#185

Post by Ar-Curunir »

ghostwriter wrote: post #159
pvg wrote: post #147

Earlier quoted context omitted.

You know the sort of person who comments 'Just install Linux' in every thread about more or less any kind of computer problem? You don't want to be that sort of person. If you're starting your comments with 'I'm not going to stop telling you to install Linux', it's probably a good time to check if you're not turning into the sort of person who's always telling you to install Linux.

If I ommited that first part of the sentence the points made afterwards would remain the same. I did so to indicate that it's not the first time the Rust community suggests that something should be (re-)written in Rust for memory-safety reasons, in a project that has a well-established C-codebase. I'd argue it's the same "Just install Linux" situation that you mention, and that "Linux" may not be the answer.

The Rust community is not advocating that, it’s kernel developers that are interested in writing new components in Rust.

So no proposal of rewriting by any Rust developers

Re: Supporting Linux kernel development in Rust

#186

Post by roca »

ghostwriter wrote: post #120
fluffy87 wrote: post #109

Earlier quoted context omitted.

I’ve used ATS, Idris and Rust, and I find ATS way more cumbersome to use for writing proofs than idris. I’ve never used ATS to do what the GP is suggesting of incrementally wrapping C with proofs, but I can’t imagine this being simpler than just rewriting the C in Rust. You wouldn’t get the same proofs, but you would get memory and thread safety, which for many apps would be an incremental improvement. I haven’t taug…

> but I can’t imagine this being simpler than just rewriting the C in Rust. sometimes it's impossible without falling back to unsafe Rust, which kind of undermines the initial incentive. C codebases heavily utilise pointer arithmetic programming. Simplicity is a good trait though, and there are a few promising initiatives in that regard in ATS3 - https://github.com/githwxi/ATS-Xanadu#project-description

"Sometimes" and "kind of" are doing a lot of work there.

In reality most Rust code hardly ever needs to be unsafe and the existence of unsafe code in libraries you use hardly ever has any impact on the security and stability of what you ship, because there just isn't very much of it compared to the safe code. The "trophy cases" for Rust fuzzing bear witness to this.

> C codebases heavily utilise pointer arithmetic programming.

You don't write unsafe Rust code everywhere C code would use pointer arithmetic. You use safe Rust idioms and APIs instead.

If it turns out that writing Linux drivers in Rust requires writing a lot of unsafe Rust code in each driver, then that would certainly be a failure. I don't see any reason to believe that will be the case.

Re: Supporting Linux kernel development in Rust

#187

Post by Ar-Curunir »

ghostwriter wrote: post #120
fluffy87 wrote: post #109

Earlier quoted context omitted.

I’ve used ATS, Idris and Rust, and I find ATS way more cumbersome to use for writing proofs than idris. I’ve never used ATS to do what the GP is suggesting of incrementally wrapping C with proofs, but I can’t imagine this being simpler than just rewriting the C in Rust. You wouldn’t get the same proofs, but you would get memory and thread safety, which for many apps would be an incremental improvement. I haven’t taug…

> but I can’t imagine this being simpler than just rewriting the C in Rust. sometimes it's impossible without falling back to unsafe Rust, which kind of undermines the initial incentive. C codebases heavily utilise pointer arithmetic programming. Simplicity is a good trait though, and there are a few promising initiatives in that regard in ATS3 - https://github.com/githwxi/ATS-Xanadu#project-description

The point of Rust is not to eliminate unsafe, but to minimize it and make the actual unsafe operations visible and easily auditable.

Re: Supporting Linux kernel development in Rust

#188

Post by roca »

einpoklum wrote: post #126
bsder wrote: post #112

Earlier quoted context omitted.

> 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.

And modern C++ features makes some memory errors more likely, e.g. dangling references from lambda captures and string_view/span.

I'm not optimistic about the safety of modern C++. Most people who really care about safety long ago left the C++ building.

Re: Supporting Linux kernel development in Rust

#189

Post by JoshTriplett »

monoideism wrote: post #157
JoshTriplett wrote: post #29

Earlier quoted context omitted.

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…

Unless the OP changed his comment, this is an overreaction to a harmless, hypothetical, technical question. I've seen a lot of annoying Rust evangelism, but this ain't it. BTW, I'm not a Rust dev, and it would appear the OP isn't a Rust developer either. They don't even seem aware of Redox. Seems odd to accuse them of "Rust evangelism".

I was not accusing the OP or anyone here of such evangelism; rather, because the OP was talking about writing/rewriting a kernel in Rust, I was stating that we weren't looking to "rewrite it in Rust" or similar. We've seen a lot of people suggesting that the work on putting Rust in Linux was trying to "rewrite the kernel", and it seemed appropriate to provide such a disclaimer.

Re: Supporting Linux kernel development in Rust

#190

Post by roca »

ghostwriter wrote: post #175
dbaupp wrote: post #156

Earlier quoted context omitted.

It's moving the goal posts and changing the point of the discussion. We can equally well say that that "Rust formally verifies your safe functions", and that this reduces how much code review is required... it's a matter of degree and specifics. Focusing on pointer manipulations is also misleading: it's entirely true that it's dangerous, but most Rust code does not need to do any sort of raw pointer manipulation. For…

> We can equally well say that that "Rust formally verifies your safe functions", and that this reduces how much code review is required... it's a matter of degree and specifics. You cannot say that while this kind of CVE is possible https://gts3.org/2019/cve-2018-1000657.html and as long as Rust is not capable of performing safe pointer manipulations. The above issue may be solved for VecDeque in stdlib, but what ab…

"In the wild" one hardly ever has to write unsafe Rust data structures and algorithms.

> If the motivation to bring a new tool is pronounced as "let's make it safe", why should we allow the argument to fallback into the "unsafe Rust" territory?

Because going from 0% of code proven safe by the compiler to 99% is very valuable. Verifying the remaining code is desirable but not as valuable as what Rust already provides.

Having said that, it would indeed be great to have a proof system for verifying properties of unsafe Rust code. Much work has been done in that area: https://alastairreid.github.io/rust-verification-tools/ Something to look forward to.

Post reply on HN