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

Blue Team Rust: What Is “Memory Safety”, Really?

tiemoko.com

Post reply on HN
Print view View original

61–70 of 105 posts

Re: Blue Team Rust: What Is “Memory Safety”, Really?

#61

Post by gameswithgo »

Recursing wrote: post #17
nullc wrote: post #16

I'm getting an increasingly bad taste from rust. In spite of the hype 9 out of 10 rust programs I download end up with a panic in my first 10 minutes of using them. Javascript is a memory safe language yet there is plenty of broken code written it it. Memory safety is a critical step forward but its wasted if it's paired with an ecosystem that thinks memory safety means that software doesn't need to be correct or is…

> 9 out of 10 rust programs I download end up with a panic in my first 10 minutes of using them. Do you have some examples? Firefox, ripgrep and fd are the only programs I use that I know are written in rust (I know only a small part of Firefox is in Rust), and they work fine for me

Sounds like a completely made up story really. Where would he find ~20 odd rust programs to download and try to report such a stat?

Re: Blue Team Rust: What Is “Memory Safety”, Really?

#62

Post by Jweb_Guru »

dataking wrote: post #7
staticassertion wrote: post #3

One thing I've realized with Rust is that its guarantees are a moving target. Today we can guarantee (barring compiler errors) memory safety in safe rust, but not unsafe rust. But that story is improving. For one thing, we have people working to build safe abstractions for more unsafe use cases, at zero cost. We also have people improving fuzzing, and in theory safe rust code grows at a much faster rate than unsafe r…

While some patterns that call for unsafe today might be eliminated in whole or part, code that violates the ownership and borrowing rules will have to remain unsafe. I think fuzzing is not guaranteed to reach all unsafe code paths, nor provide full test coverage. Ideally, you want a) some sort of formal proof that the unsafe code cannot violate memory safety, b) 100% branch coverage for unsafe code, or c) both (becau…

Unsafe Rust can be (and has been) formally verified to satisfy its Rust type, meaning calling it from safe code can't violate memory unsafety. We don't need to trust manual inspection.

Re: Blue Team Rust: What Is “Memory Safety”, Really?

#63

Post by steveklabnik »

Jweb_Guru wrote: post #62
dataking wrote: post #7

Earlier quoted context omitted.

While some patterns that call for unsafe today might be eliminated in whole or part, code that violates the ownership and borrowing rules will have to remain unsafe. I think fuzzing is not guaranteed to reach all unsafe code paths, nor provide full test coverage. Ideally, you want a) some sort of formal proof that the unsafe code cannot violate memory safety, b) 100% branch coverage for unsafe code, or c) both (becau…

Unsafe Rust can be (and has been) formally verified to satisfy its Rust type, meaning calling it from safe code can't violate memory unsafety. We don't need to trust manual inspection.

IMHO, this is going a bit too far. Some parts of unsafe Rust have had a model produced that can check some of the invariants required for safe Rust. For example, in my understanding, traits were not modeled at all. Still very promising work, but don't want to overstate it either!

Re: Blue Team Rust: What Is “Memory Safety”, Really?

#64

Post by Ar-Curunir »

nullc wrote: post #16

I'm getting an increasingly bad taste from rust. In spite of the hype 9 out of 10 rust programs I download end up with a panic in my first 10 minutes of using them. Javascript is a memory safe language yet there is plenty of broken code written it it. Memory safety is a critical step forward but its wasted if it's paired with an ecosystem that thinks memory safety means that software doesn't need to be correct or is…

Care to back up your claim with some evidence?

Re: Blue Team Rust: What Is “Memory Safety”, Really?

#65

Post by jfkebwjsbx »

burntsushi wrote: post #10
Animats wrote: post #5

Earlier quoted context omitted.

Today we can guarantee (barring compiler errors) memory safety in safe rust, but not unsafe rust. Not quite. An unsafe function can export its lack of safety to other code. If an unsafe function can be called with parameters which make it violate memory safety, it opens a hole in memory safety.

Calling an unsafe function can only be done inside an unsafe block.

They say can call though, so they are correct: if you can call then you are in an unsafe context.

Re: Blue Team Rust: What Is “Memory Safety”, Really?

#66

Post by Ar-Curunir »

nullc wrote: post #28
nestorD wrote: post #25

Earlier quoted context omitted.

Note that the use of the word "panic" in Rust can be a bit misleading. It is not equivalent to a segfault in C/C++ but rather to a volontarily uncaught exception, killing the application.

It's that kind of thinking that likely contributes to the low software quality. The software failed and did so in a user uninformative way. Except in things like network facing software or whatnot --where a segfault might also be an RCE--, a panic is not superior to a segfault. A panic can even still be a vulnerability: DOS attacks are attacks too. That the failure isn't one that could have resulted in an RCE is only…

Rust software is of consistently higher quality than most C/C++ software that I use, both in terms of reliability and in terms of UX. I don’t know where you’re getting your claims from.

Re: Blue Team Rust: What Is “Memory Safety”, Really?

#67

Post by ben-schaaf »

nullc wrote: post #28
nestorD wrote: post #25

Earlier quoted context omitted.

Note that the use of the word "panic" in Rust can be a bit misleading. It is not equivalent to a segfault in C/C++ but rather to a volontarily uncaught exception, killing the application.

It's that kind of thinking that likely contributes to the low software quality. The software failed and did so in a user uninformative way. Except in things like network facing software or whatnot --where a segfault might also be an RCE--, a panic is not superior to a segfault. A panic can even still be a vulnerability: DOS attacks are attacks too. That the failure isn't one that could have resulted in an RCE is only…

> The software failed and did so in a user uninformative way.

How is this different to any other crash in terms of user information? Whether it segfault or panics is just as uninformative.

Ignoring vulnerabilities here, a SEGV catches memory bugs, but it can only catch those that result in accessing an invalid region of memory. There's plenty of memory bugs that do not result in a SEGV and instead just corrupt the program state possibly causing all kinds of damage. eg. if `rm` had a memory bug with the paths it read it could be catastrophic. Safe rust prevents all those memory bugs, instead causing a panic. I don't know about you but I'd much rather have a program panic than continue running in an invalid/corrupted state.

Re: Blue Team Rust: What Is “Memory Safety”, Really?

#68

Post by jfkebwjsbx »

steveklabnik wrote: post #57
Const-me wrote: post #55

Earlier quoted context omitted.

> that’s checked in Rust too In safe Rust. Safe C# is the same, it doesn’t even have raw pointers in the language unless compiling with /unsafe, and writing code in unsafe blocks. > More like “write to this register” than “here’s a complex data structure.” I sometimes write C++ DLLs precisely to implement these complex data structures. Modern CPUs have progressively worse proportion of RAM latency / compute speed. Th…

They’re checked in unsafe too. You only skip those checks if you use a specific “do this index with no checks” function. Unsafe does not change the semantics of code, only gives you more options. Yes, and many people write that kind of code in Rust too, and use tools to help them debug it. I’m just saying that it’s not an issue for the kinds of code I write, so I can’t personally recommend tooling. I know "use GDB" i…

However you put it, tooling support is way, way better for C and C++ for obvious reasons.

Other critical bits for commercial development in many industries (certs, standards, third-party support, official bindings...) are also completely lacking.

That is not something against Rust, it is just what happens until things get popular enough.

Re: Blue Team Rust: What Is “Memory Safety”, Really?

#69

Post by burntsushi »

jfkebwjsbx wrote: post #65
burntsushi wrote: post #10

Earlier quoted context omitted.

Calling an unsafe function can only be done inside an unsafe block.

They say can call though, so they are correct: if you can call then you are in an unsafe context.

Yes...? But they're responding to a point about safe Rust. See my other comment: https://news.ycombinator.com/item?id=24028359

Re: Blue Team Rust: What Is “Memory Safety”, Really?

#70

Post by steveklabnik »

jfkebwjsbx wrote: post #68
steveklabnik wrote: post #57

Earlier quoted context omitted.

They’re checked in unsafe too. You only skip those checks if you use a specific “do this index with no checks” function. Unsafe does not change the semantics of code, only gives you more options. Yes, and many people write that kind of code in Rust too, and use tools to help them debug it. I’m just saying that it’s not an issue for the kinds of code I write, so I can’t personally recommend tooling. I know "use GDB" i…

However you put it, tooling support is way, way better for C and C++ for obvious reasons. Other critical bits for commercial development in many industries (certs, standards, third-party support, official bindings...) are also completely lacking. That is not something against Rust, it is just what happens until things get popular enough.

Absolutely. All I’m saying is that it’s non-zero, not that it’s equivalent.
Post reply on HN