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

51–60 of 105 posts

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

#51

Post by steveklabnik »

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

Earlier quoted context omitted.

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,…

I mean, if you’re talking about checked iterators... that’s checked in Rust too.

I am 100% Windows, but don’t triage these issues often enough to suggest tools; the unsafe code I write tends to be small and pretty obvious. (More like “write to this register” than “here’s a complex data structure.”)

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

#52

Post by burntsushi »

the_duke wrote: post #13
burntsushi wrote: post #10

Earlier quoted context omitted.

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

I assume OP s point is that unsoundness or UB in an unsafe block is not contained in that block, but can taint safe code anywhere in the program. Which is true.

Yes, it's true, but that wasn't what Animats said. And even if that was Animats' point, it doesn't invalidate the GP. The key value proposition of Rust isn't that "you'll never have memory safety bugs," but rather, that if your unsafe code is correct and sound, then safe Rust will be free of memory safety bugs. The important bit is the implication that grants one the power to make that sort of reasoning. It's important precisely because it limits the places in your code that need to be audited.

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

#53

Post by touisteur »

Animats wrote: post #6
saagarjha wrote: post #2

> Bounds checks are more effective than the stack cookies a C compiler might insert because they still apply when indexing linear data structures, an operation that's easier to get right with Rust's iterator APIs. Not only that, bounds checks always work, while stack cookies are possible to bypass either by luck or by information disclosure.

The key thing with bounds checks is to hoist them out of inner loops. If you don't have that optimization, people will turn them off because of the performance impact. Except in inner loops, the performance penalty isn't usually that bad.

Or prove the impossibility of bounds-check failing and then disable them. The perfect use-case for silver-level SPARK. It would make sense to require some proof effort when you want to disable runtime checks...

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

#54

Post by burntsushi »

saagarjha wrote: post #11
burntsushi wrote: post #10

Earlier quoted context omitted.

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

I’m unsure what you’re responding to. As I understood it, the comment took issue with saying that you can make guarantees about safe Rust but not unsafe Rust because unsafe Rust is not verified in that way and opens the door to violating guarantees in your “safe” code if your bugs leak out.

That may be what you understood, but that's not what Animats said. See my reply above for more of an elaboration: https://news.ycombinator.com/item?id=24028359

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

#55

Post by Const-me »

steveklabnik wrote: post #51
Const-me wrote: post #49

Earlier quoted context omitted.

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,…

I mean, if you’re talking about checked iterators... that’s checked in Rust too. I am 100% Windows, but don’t triage these issues often enough to suggest tools; the unsafe code I write tends to be small and pretty obvious. (More like “write to this register” than “here’s a complex data structure.”)

> 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. This means you need full control over memory layout of data on the performance critical paths of code, or it will be slow.

Also, many external APIs have incredibly complex unsafe structures. Here’s a piece of Linux kernel API I have recently consumed in C#: https://www.kernel.org/doc/html/v4.20/media/uapi/v4l/v4l2.ht... Way more complicated than writing registers.

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

#56

Post by burntsushi »

tsimionescu wrote: post #22
burntsushi wrote: post #10

Earlier quoted context omitted.

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

But you can expose unsafe code with a safe API, right? The point of the GP was that any safe code using this safe API could in fact be memory unsafe is there is a bug in the unsafe implementation.

Yes, of course you can. But that's not what Animats said. Animats specifically said "unsafe function," which means you need to use the unsafe annotation to call it. See my other reply for more elaboration: https://news.ycombinator.com/item?id=24028359

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

#57

Post by steveklabnik »

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

Earlier quoted context omitted.

I mean, if you’re talking about checked iterators... that’s checked in Rust too. I am 100% Windows, but don’t triage these issues often enough to suggest tools; the unsafe code I write tends to be small and pretty obvious. (More like “write to this register” than “here’s a complex data structure.”)

> 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" isn't a great response to a Windows user, even if it is what I end up personally doing.

Funny enough, I just booted up VS, and it's not perfect, but https://imgur.com/a/kHvPIEr

(It's true that I can't get the performance tools working though, but given I've used VS for all of 20 minutes... I'm also very interested to see if support happens native-ly, given how much interest there is for Rust inside of Microsoft right now.)

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

#59

Post by gameswithgo »

Animats wrote: post #6
saagarjha wrote: post #2

> Bounds checks are more effective than the stack cookies a C compiler might insert because they still apply when indexing linear data structures, an operation that's easier to get right with Rust's iterator APIs. Not only that, bounds checks always work, while stack cookies are possible to bypass either by luck or by information disclosure.

The key thing with bounds checks is to hoist them out of inner loops. If you don't have that optimization, people will turn them off because of the performance impact. Except in inner loops, the performance penalty isn't usually that bad.

The idiomatic thing to do in rust is use iterators, and bounds checks are elided when you do. You can't always use iterators of course, at which point llvm is there to optimize what it can.

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

#60

Post by gameswithgo »

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…

>Javascript is a memory safe language yet there is plenty of broken code written it it.

Rust has a lot of safety features javascript doesn't, like lack of null, and data race protection..and types. But the biggest difference is Rust gets you memory safety AND C/C++ performance.

Post reply on HN