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

“Rust is safe” is not some kind of absolute guarantee of code safety

lkml.org

Post reply on HN
Print view View original

521–530 of 542 posts

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#521

Post by wtallis »

kaba0 wrote: post #508
wtallis wrote: post #336

Earlier quoted context omitted.

> You could simply write crash info to some NVRAM or something, and then do a reboot. Then you can recover it during the next boot. That works for some systems: those for which "some NVRAM or something" evaluates to a real device usable for that purpose. Not all Linux systems provide such a device. > But there is no need to let userspace processes continue to run, which is exactly what Linux does. Userspace processes…

Isn’t that exactly the reason behind microkernel’s supposed superiority?

It's the primary claimed benefit to microkernels. But since Linux as it exists today already handles this case, it isn't a very strong argument in favor of microkernels.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#522

Post by pjmlp »

ajross wrote: post #282
jmillikin wrote: post #130

Earlier quoted context omitted.

Rust doesn't have an official `#[never_panic]` annotation, but there's a variety of approaches folks use. Static analysis (Clippy) can get you pretty far. My favorite trick is to link a no_std binary with no panic handler, and see if it has a linker error. No linker error = no calls to panic handler = no panics. Note that Rust is easier to work with than C here, because although the C-like API isn't shy about panicki…

> Static analysis (Clippy) can get you pretty far. What's funny about this is that (while it's true!) it's exactly the argument that Rustaceans tend to reject out of hand when the subject is hardening C code with analysis tools (or instrumentation gadgets like ASAN/MSAN/fuzzing, which get a lot of the same bile). In fact when used well, my feeling is that extra-language tooling has largely eliminated the practical sa…

Static analysis for C exists since 1979, date of lint's availability, the problem isn't lack of tooling, rather people actually using it.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#523

Post by pjmlp »

lifthrasiir wrote: post #301
ajross wrote: post #282

Earlier quoted context omitted.

> Static analysis (Clippy) can get you pretty far. What's funny about this is that (while it's true!) it's exactly the argument that Rustaceans tend to reject out of hand when the subject is hardening C code with analysis tools (or instrumentation gadgets like ASAN/MSAN/fuzzing, which get a lot of the same bile). In fact when used well, my feeling is that extra-language tooling has largely eliminated the practical sa…

While C/C++ has been made much safer by sanitizers, fuzzing and lints, they are: - Only useful when actually being used, which is never the case. (Seriously, can we make at least ASAN the default?) - Often costly to always turn them on (e.g. MSAN). - Often requires restructuring or redesign to get the most out of them (especially fuzzing). Rust's memory safety guarantee does not suffer from first two points, and the…

> Seriously, can we make at least ASAN the default?

Android helps a bit into that sense,

https://source.android.com/docs/security/test/hwasan

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#524

Post by pjmlp »

paoda wrote: post #518
greyhair wrote: post #516

Earlier quoted context omitted.

> Most code written in C is horribly unsafe. I think that is untrue. I worked at the Network Systems arm of Bell Labs for sixteen years, and we could demonstrate five-nines of uptime on complex systems written entirely in C. C is a rough tool, I will grant you that, and Rust is a welcome addition to the toolkit, but saying that most code written in C is horribly unsafe, does not make it true.

Perhaps I misunderstand, but I don't imagine most individuals or companies writing production C code to be on the same "level of competency" as a research company as prestigious as Bell Labs.

UNIX was found to be less secure than Multics, thanks to the additional safety guarantees provided by PL/I type system.

https://www.acsac.org/2002/papers/classic-multics.pdf

So not even back then.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#525

Post by 0xbeefeed »

Well, this had to happen at some point. Rust-for-Kernel isn’t just a second language. It’s another culture. A culture that is in clash with kernel community. This project should be halted right now, instead of wasting thousands of man-hours only to be stopped later. There is no way these two cultures would go along for long.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#526

Post by nickm12 »

mid-kid wrote: post #65
mynameisvlad wrote: post #58

Earlier quoted context omitted.

It’s crazy to think that advocating for reasonable, non-toxic people to work with receives this kind response. Inclusivity and non-hostile work environments should not be considered “perfect” and “all-inclusive”. They should be basic . The default . The lowest bar possible .

Just as many people have problems with this form of communication, many people find it hard to clearly express themselves in an environment where they're expected to put people's feelings above all else. What some might perceive as "hostile", others would simply call "honest". It's simply a matter of preference.

The choice between condescension to your collaborators and putting people's feeling "above all else" is a false dichotomy. You can disagree on technical merits without making it personal and calling your collaborators kindergarteners who believe in Santa Claus.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#527

Post by nickm12 »

zozbot234 wrote: post #315
mynameisvlad wrote: post #58

Earlier quoted context omitted.

It’s crazy to think that advocating for reasonable, non-toxic people to work with receives this kind response. Inclusivity and non-hostile work environments should not be considered “perfect” and “all-inclusive”. They should be basic . The default . The lowest bar possible .

So an "inclusive" and "non-toxic work environment" should put fantasy above reality? There's nothing inherently toxic in Linus' message; he's making a technical point about how kernel code should be designed, to deal effectively with the sometimes complex and challenging reality of low-level systems.

He is implying that his collaborators are kindergarteners who believe in Santa Claus. It's insulting.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#528

Post by zozbot234 »

nickm12 wrote: post #527
zozbot234 wrote: post #315

Earlier quoted context omitted.

So an "inclusive" and "non-toxic work environment" should put fantasy above reality? There's nothing inherently toxic in Linus' message; he's making a technical point about how kernel code should be designed, to deal effectively with the sometimes complex and challenging reality of low-level systems.

He is implying that his collaborators are kindergarteners who believe in Santa Claus. It's insulting.

He's doing no such thing. He's saying "surely you're well past kindergarten and don't believe in Santa Claus, so why would you ever believe this?" It's a valid argument.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#529

Post by jstimpfle »

pjmlp wrote: post #522
ajross wrote: post #282

Earlier quoted context omitted.

> Static analysis (Clippy) can get you pretty far. What's funny about this is that (while it's true!) it's exactly the argument that Rustaceans tend to reject out of hand when the subject is hardening C code with analysis tools (or instrumentation gadgets like ASAN/MSAN/fuzzing, which get a lot of the same bile). In fact when used well, my feeling is that extra-language tooling has largely eliminated the practical sa…

Static analysis for C exists since 1979, date of lint's availability, the problem isn't lack of tooling, rather people actually using it.

I would assume that the things that lint could do you nowadays get by simply using -Wall -Wextra with gcc for example. While I haven't checked what a lint is required to do, but there have been plenty of situations in the past where I had to change my code in order to avoid triggering false positives from tests that run during normal compilation. For instance, there are tests that find accesses to potentially uninitialized variables.
Post reply on HN