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

11–20 of 105 posts

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

#11

Post by saagarjha »

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.

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.

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

#12

Post by PudgePacket »

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.

Can you rephrase or restate your point? It's really hard to understand..

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

#13

Post by the_duke »

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.

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.

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

#14

Post by saagarjha »

PudgePacket wrote: post #12
saagarjha wrote: post #11

Earlier quoted context omitted.

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.

Can you rephrase or restate your point? It's really hard to understand..

“Your comment doesn’t really make sense, https://news.ycombinator.com/item?id=24027224 “

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

#15

Post by connicpu »

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.

Reminds me of an interesting thing I noticed, a few times the compiler has been able to make a tighter inner loop simply by adding an `assert!` on the array length before the loop. I guess the compiler considers the specific error message that will be printed to be a side effect, so the assert moves that check to before the loop instead of at some point during the loop.

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

#16

Post by nullc »

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 so fixated on reimplementing things for "memory safety" that understanding the problem domain and actually making things that work falls by the wayside.

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

#17

Post by Recursing »

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

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

#18

Post by drran »

Animats wrote: post #5
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…

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.

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

#19

Post by EE84M3i »

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…

Why does code violating the rules have to stay unsafe? Haven't the rules been improved before? Why won't they be improved again?

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

#20

Post by IshKebab »

zozbot234 wrote: post #9
Animats wrote: post #6

Earlier quoted context omitted.

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 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 an explicit way of forcing an error if the bounds check was not hoisted. Similar story for lots of other optimisations - autovectorisation, tail call optimization, etc.

Some game developer made a good point that sometimes fast is correct, i.e. it's actually a bug if autovectorisation or whatever doesn't happen, so you really need a way to guarantee it.

Post reply on HN