Blue Team Rust: What Is “Memory Safety”, Really?
1–10 of 105 posts
Re: Blue Team Rust: What Is “Memory Safety”, Really?
#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.
Re: Blue Team Rust: What Is “Memory Safety”, Really?
#3One 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 rust code, so fuzzing is far more tractable. We have people working on proving more about rust code, even when unsafe is around.
I'm quite excited to see how far Rust is able to go, I don't believe the state today is the end at all.
Re: Blue Team Rust: What Is “Memory Safety”, Really?
#4> 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.
And in some (though likely rare) cases you can even access the memory where the reference is and overwrite both that and the cookie.
Re: Blue Team Rust: What Is “Memory Safety”, Really?
#5One 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.
Re: Blue Team Rust: What Is “Memory Safety”, Really?
#6> 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.
Re: Blue Team Rust: What Is “Memory Safety”, Really?
#7One 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 (because profilers and proofs can be wrong too :)
edit: grammar.
Re: Blue Team Rust: What Is “Memory Safety”, Really?
#8> 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.
Speculative execution mitigations throw in another performance wrench. Might as well drop the need for them altogether, which is what happens with a lot of the integrator constructs we have in modern languages.
Re: Blue Team Rust: What Is “Memory Safety”, Really?
#9> 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 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.
Re: Blue Team Rust: What Is “Memory Safety”, Really?
#10One 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.
Calling an unsafe function can only be done inside an unsafe block.