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

41–50 of 105 posts

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

#41

Post by imtringued »

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…

Are you sure this isn't just confirmation bias? When a program "panics" then its easy to conclude that it must be a Rust program but if it doesn't then aren't you simply forgetting to count all the working Rust programs?

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

#42

Post by steveklabnik »

Const-me wrote: post #36
drran wrote: post #18

Earlier quoted context omitted.

Yep. For example, it's easy to make intentional memory leak in Rust using safe API, which is unsafe. However, it's also easy to find such memory leak. Rust cannot stop you from doing weird things, when you want this, but it can help you to prevent, or quickly find, weird things, when you don't want them in your code.

> However, it's also easy to find such memory leak. How? By manually inspecting all code in the project + dependencies marked with "unsafe"? The approach doesn't scale past "hello world" level of complexity. I don't code Rust, using C# for same purpose. I remember couple times I spend hours debugging weird crashes caused by stupid bugs in totally unrelated unsafe C# code. It's much easier to find memory leaks or nati…

You can also use those tools on Rust. It looks close enough that’s it’s fine. Valgrind, fuzzers, that stuff still works.

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

#43

Post by nicoburns »

IshKebab wrote: post #20
zozbot234 wrote: post #9

Earlier quoted context omitted.

> The key thing with bounds checks is to hoist them out of inner loops. The compiler can't always hoist the check on its own, because program behavior might depend on the bounds check occurring in the loop. But you can write an assert!() outside the loop to hoist it explicitly, and verify that the bounds checks are optimized away - or use unsafe unchecked access when they aren't.

How do you write the assert? I've not heard of that before. Oh you mean `assert!(array.len() > 100); for i in 0..100 { array[I]; }` I don't think that guarantees that bounds checks will be hoisted. It's just a strong hint. I mean in this case it will almost certainly work, but in more complexes cases it might not and the compiler is still free to emit bounds checks without telling you. It would be nice if there was a…

In Rust, the way to force removal of bounds checks is to use iterators rather than a for loop.

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

#44

Post by kd5bjo »

foota wrote: post #32
zozbot234 wrote: post #30

Earlier quoted context omitted.

This requires a formal semantics for Unsafe Rust. It's a hard problem, albeit one that's being worked on.

I'm aware that however it's done it'll be hard. Does it really require formal semantics for unsafe rust though? I'm not familiar enough with rust to give an example, but if you imagine there's the unsafe rust level and beneath that the "machine code" (not actually machine code, just at the abstraction level equivalent to it) you should be able to hand write what the rust code is doing, without requiring the compiler…

> With a proof written at machine level, you don't need to understand the rust semantics, you just need to translate the rust to machine level and then check the proof there.

This approach would only be able to verify a particular compilation result as safe. If you want to verify that it will always be safe, you need to be comparing against the behavior of future compilers, which requires some kind of contract about their behavior. “Formal semantics” is the technical term for that contract.

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

#46

Post by historyremade »

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…

Greg, I agree with you on this...

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

#47

Post by bennofs »

foota wrote: post #32
zozbot234 wrote: post #30

Earlier quoted context omitted.

This requires a formal semantics for Unsafe Rust. It's a hard problem, albeit one that's being worked on.

I'm aware that however it's done it'll be hard. Does it really require formal semantics for unsafe rust though? I'm not familiar enough with rust to give an example, but if you imagine there's the unsafe rust level and beneath that the "machine code" (not actually machine code, just at the abstraction level equivalent to it) you should be able to hand write what the rust code is doing, without requiring the compiler…

The problem is that the unsafe-safe boundary needs to be specified. Unsafe code often relies on invariants ensured due to safe rust's checks. Also, there are properties that unsafe code has to satisfy which are special to rust, for example involving rules around special traits like `Drop`. So even if the unsafe code itself could be proven to have no memory corruptions, if it does not satisfy these invariants, it could lead to wrong behaviour in other parts of the program.

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

#48

Post by PudgePacket »

vinay_ys wrote: post #34
XMPPwocky wrote: post #31

Earlier quoted context omitted.

only if that block, or something in its "trusted set" (my term, for things in the same module that can access private members) is incorrect, though. safety/unsafety in Rust is factorable , which is a key part of the reason Rust is useful at all.

Rest of your program blindly believes that the interface of your "trusted set" is safe because you owned that responsibility when you marked it unsafe. If you have a memory safety bug in that interface, then you can taint the rest of the program's memory safety as well, correct?

Yes, that's the whole point though.

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

#49

Post by Const-me »

steveklabnik wrote: post #42
Const-me wrote: post #36

Earlier quoted context omitted.

> However, it's also easy to find such memory leak. How? By manually inspecting all code in the project + dependencies marked with "unsafe"? The approach doesn't scale past "hello world" level of complexity. I don't code Rust, using C# for same purpose. I remember couple times I spend hours debugging weird crashes caused by stupid bugs in totally unrelated unsafe C# code. It's much easier to find memory leaks or nati…

You can also use those tools on Rust. It looks close enough that’s it’s fine. Valgrind, fuzzers, that stuff still works.

Simpler stuff like debug C heap, and checked iterators in C++ standard library, catch 95% of memory corruption issues in C++. These are enabled by default in debug builds, very often just pressing F5 in visual studio finds the buggy line of code in a matter of seconds.

Valgrind is Linux-only, I don’t have it. One Windows equivalent is memory profiler under Debug / Performance Profiler / Memory Usage in visual studio, Rust is not supported by visual studio. A cross-platform equivalent is Intel VTune Profiler, no support for Rust either.

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

#50

Post by qppo »

drran wrote: post #18
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.

Yep. For example, it's easy to make intentional memory leak in Rust using safe API, which is unsafe. However, it's also easy to find such memory leak. Rust cannot stop you from doing weird things, when you want this, but it can help you to prevent, or quickly find, weird things, when you don't want them in your code.

Memory leaks are not memory unsafe.
Post reply on HN