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

Rust in the kernel is no longer experimental

lwn.net

Post reply on HN
Print view View original

661–670 of 853 posts

Re: Rust in the kernel is no longer experimental

#661

Post by stusmall »

embedding-shape wrote: post #420
pta2002 wrote: post #295

Earlier quoted context omitted.

A few distros already do that. Of the top of my head, both NixOS and Arch enable the QR code kernel panic screen, which is written in Rust. Granted, those are rather bleeding edge, but I know a few more traditional distros have that enabled (I _think_ fedora has it? But not sure).

> both NixOS and Arch enable the QR code kernel panic screen Interesting, I use both (NixOS on servers, Arch for desktop) and never seen that. Seems you're referring to this: https://rust-for-linux.com/drm-panic-qr-code-generator (which looks like this: https://github.com/kdj0c/panic_report/issues/1 ) Too bad NixOS and Arch is so stable I can't remember the last time any full system straight up panicked.

You can force a panic with echo c | /proc/sysrq-trigger

Re: Rust in the kernel is no longer experimental

#662

Post by menaerus »

Xylakant wrote: post #657
zozbot234 wrote: post #570

Earlier quoted context omitted.

> The practice of encapsulation enables local reasoning about safety invariants. > The additional scrutiny that unsafe{} blocks receive. None of this supports an argument that "unsafe Rust is safer than C". It's just saying that with enough scrutiny on those unsafe blocks, the potential bugs will be found and addressed as part of development. That's a rather different claim.

It does, if you read the report and run a little (implied) math. The report says that their historical data gives them an estimate of 1000 Memory Safety issues per Million Lines of Code for C/C++. The same team currently has 5 Million lines of Rust code, of which 4% are unsafe (200 000). Assuming that unsafe Rust is on par with C/C++, this gives us an expected value of about 200 memory safety issues in the unsafe cod…

They say "With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC).".

Do you honestly believe that there is 1 vulnerability per 5 MLoC?

Re: Rust in the kernel is no longer experimental

#663

Post by albuic »

freeopinion wrote: post #453
timschmidt wrote: post #428

Earlier quoted context omitted.

> Rustians disparage C No, the 50+ years of ridiculously unavoidable memory corruption errors have done more to disparage C than anyone working in another language.

I don't think C should be disparaged at all. Just because I prefer torx screws doesn't mean phillips screws were a horrible idea. They were brilliantly simple and enormously effective. I can't think of a single situation in which I wouldn't prefer torx, but torx wasn't an option historically and phillips was not the wrong decision at the time. Times change.

So should the tools.

Re: Rust in the kernel is no longer experimental

#664

Post by integralid »

irusensei wrote: post #389

Happy to hear. We should embrace new things.

Why? New things are less stable, immature and require a lot of effort to understand.

Don't get me wrong, rust in the kernel is good, because the memory safety and expressiveness it brings makes it worth it DESPITE the huge effort required to introduce it. But I disagree that new things are inherently good.

Re: Rust in the kernel is no longer experimental

#665

Post by bigyabai »

baq wrote: post #235
bigyabai wrote: post #194

Earlier quoted context omitted.

> it always has been and always will be available everywhere "Always has been" is pushing it. Half of C's history is written with outdated, proprietary compilers that died alongside their architecture. It's easy to take modern tech like LLVM for granted.

This might actually be a solved problem soonish, LLMs are unreasonably effective at writing compilers and C is designed to be easy to write a compiler for, which also helps. I don’t know if anyone tried, but there’s been related work posted here on HN recently: a revived Java compiler and the N64 decompilation project. Mashed together you can almost expect to be able to generate C compilers for obscure architectures…

Which is neat! But if you care about performance, you're probably using Clang to compile for your esoteric architecture. And if your esoarch already supports LLVM... might as well write Rust instead.

Re: Rust in the kernel is no longer experimental

#666

Post by nextaccountic »

estebank wrote: post #624
steveklabnik wrote: post #597

Earlier quoted context omitted.

For what it’s worth, I perceived hostility here a long time ago, but those people have pretty explicitly come around since. That said I also think the parent is just wrong to focus on gcc vs llvm as the source of that, and also to bring it up at this point regardless.

The only thing I could ever see misconstrued of as "hostility" with my earshot from anyone in t-compiler is myself saying something along the lines of "that sounds like a lot of effort that doesn't gain much over rustc_codegen_gcc, and I am not interested in contributing to a cpp codebase". Note that nowhere in my position I state anything like "this shouldn't exist" or "they should stop" or "we shouldn't cooperate".…

There's another point of hostility when it was expressed - not sure by who - that internals.rust-lang.org wasn't an appropriate forum to discuss gccrs

Generally speaking I think that Rust channels should be open to all implementations

Re: Rust in the kernel is no longer experimental

#667

Post by NetMageSCW »

Ygg2 wrote: post #327
sayamqazi wrote: post #101

Earlier quoted context omitted.

Pardon my ignorance but I find the claim "removing the nastiest cla ss of security vulnerabilities" to be a bold claim. Is there ZERO use of "unsafe" rust in kernel code??

It removes a class of security vulnerabilities, modulo any unsound unsafe (in compiler, std/core and added dependency). In practice you see several orders of magnitude fewer segfaults (like in Google Android CVE). You can compare Deno and Bun issue trackers for segfaults to see it in action. As mentioned a billion times, seatbelts don't prevent death, but they do reduce the likelihood of dying in a traffic accident.…

“by removing the nastiest class of security vulnerabilities” and “reduce the likelihood” don’t seem to be in the same neighborhood.

Re: Rust in the kernel is no longer experimental

#668

Post by menaerus »

baq wrote: post #647
zozbot234 wrote: post #570

Earlier quoted context omitted.

> The practice of encapsulation enables local reasoning about safety invariants. > The additional scrutiny that unsafe{} blocks receive. None of this supports an argument that "unsafe Rust is safer than C". It's just saying that with enough scrutiny on those unsafe blocks, the potential bugs will be found and addressed as part of development. That's a rather different claim.

literally from the quote: unsafe{} doesn't actually disable all or even most of Rust’s safety checks (a common misconception).

They also say

  The practice of encapsulation enables local reasoning about safety invariants.
which is not fully correct. Undefined behavior in unsafe blocks can and will leak into the safe Rust code so there is nothing there about the "local reasoning" or "encapsulation" or "safety invariants".

This whole blog always read to me as too much like a marketing material disguised with some data so that it is not so obvious. IMHO

Re: Rust in the kernel is no longer experimental

#669

Post by pornel »

muvlon wrote: post #425
bmicraft wrote: post #292

Earlier quoted context omitted.

Which ones would that be?

In order to figure this out I took the list of platforms supported by Rust from https://doc.rust-lang.org/nightly/rustc/platform-support.htm... and those supported by Linux from https://docs.kernel.org/arch/index.html , cleaned them up so they can be compared like for like and then put them into this python script: linux = { "alpha", "arc", "arm", "aarch64", "csky", "hexagon", "loongarch", "m68k", "microblaze", "mips…

There's Rust for Dreamcast (https://dreamcast.rs) via Rust's GCC backend.

Re: Rust in the kernel is no longer experimental

#670

Post by jjice »

ls-a wrote: post #588
jjice wrote: post #569

Earlier quoted context omitted.

It's an optional tool that can be used to implement drivers now, not forced. If you don't like the idea of another language being supported for implementing a subset of kernel modules, I don't think you wouldn't enjoyed having a Linux machine anyways.

That's not the case. It's using Rust as a selling point. All the noise around using Rust is marketing. The fact that you think linux machines are enjoyed by only a specific group of people makes me happier with my choice

> That's not the case. It's using Rust as a selling point

"Rust as a selling point" was a big thing in 2018-2022ish. You see it a lot less of the "written in Rust" in HN headlines these days. Some people were very excited about Rust early on. What feels more common today are people who unnecessarily hate Rust because they saw too much of this hype and they (justifiably) got annoyed by it.

If there is a new, optional language to be added to Linux Kernel development, Rust makes sense. It's a low level, performant, and safe language. Introducing it for driver development has almost no impact on 99% of users, except maybe it'll safe them a memory related bug fix patch having to be installed at some point. Is Rust the "selling point" here, or is the potential to avoid an entire class of bugs the selling point?

> The fact that you think linux machines are enjoyed by only a specific group of people makes me happier with my choice

If by "specific group of people" you mean "people who will refuse to use an OS based on the implementation language(s)", then I guess so.

I don't mean to be rude (although it reads like it, apologies), but I just think that you're coming at this from a perspective of malice instead of what the goal was, which was to reduce bugs in kernel drivers, and not to pimp Rust as a programming language by getting it into a large software project.

Post reply on HN