Blue Team Rust: What Is “Memory Safety”, Really? • Hacker News Board

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

#81

Post by nestorD » Sun, Aug 02, 2020, 4:58 PM UTC

ben-schaaf wrote: post #67

nullc wrote: post #28

Earlier quoted context omitted.

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

> Safe rust prevents all those memory bugs, instead causing a panic.

Rust is even stronger than that, in the vast majority of cases, panics are not related to memory bugs as those are caught at compile time in Rust (panics are usually the quick and dirty way to deal with invalid files names and such things, as Rust refuses to accept those silently).

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

#82

Post by ridiculous_fish » Sun, Aug 02, 2020, 5:35 PM UTC

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.

It's hard to know if that optimization is active, and nearly impossible to ensure that it stays active. So for this to work, it would need to be enforced, e.g. the same way that the compiler enforces that a let binding is assigned before use.

Top of my wish list is better support for debug-checked indexing. It would be extremely useful if unsafe get had bounds checking in debug mode.

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

#83

Post by dthul » Sun, Aug 02, 2020, 5:36 PM UTC

bluejekyll wrote: post #75

dthul wrote: post #37

Earlier quoted context omitted.

Not to discredit you, but you postulate things like "9 out of 10 times" and generally "low software quality" but don't support your statements. It certainly is not my experience that this is (more, or at all) common in the Rust ecosystem. If an application author uses things like unwrap or expect (two of the most common ways to abort the program with a panic) that is indeed lazy software engineering. But these are al…

> lazy software engineering For production code, I agree with you. When writing PoC software, using those can speed up development, rather than forcing you to figure out the best way to deal with those options or errors upfront. Refactoring in Rust tends to also make it reliably produce production quality code when you go back and fix all that. On the “?” In examples, that can also lead to annoyance for a new to Rust…

Oh yeah absolutely, for prototypes you can liberally use unwrap/expect to figure out the happy path first and remove those calls later.

I haven't checked out the Rust book in quite some time, but it would be cool to make newcomers comfortable with the Result> return type early on, so they know what they have to do to make code containing "?" compile.

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

#84

Post by drran » Sun, Aug 02, 2020, 5:42 PM UTC

EE84M3i wrote: post #21

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.

"For example, it's easy to make intentional memory leak in Rust using safe API, which is unsafe." In what way is leaking memory in rust unsafe?

It's a safe way to crash program by OOM killer. :-)

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

#85

Post by ridiculous_fish » Sun, Aug 02, 2020, 5:44 PM UTC

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…

Lots of talk about formal methods, but I think the high order bit would be for unsafe code to use debug_assert! to check its preconditions.

Right now it doesn't, because of rather silly technical reasons regarding how libcore is built and tested.

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

#86

Post by nullc » Sun, Aug 02, 2020, 6:01 PM UTC

dthul wrote: post #37

nullc wrote: post #28

Earlier quoted context omitted.

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…

Not to discredit you, but you postulate things like "9 out of 10 times" and generally "low software quality" but don't support your statements. It certainly is not my experience that this is (more, or at all) common in the Rust ecosystem. If an application author uses things like unwrap or expect (two of the most common ways to abort the program with a panic) that is indeed lazy software engineering. But these are al…

I do have a list of 10. I don't really feel comfortable posting it because I don't want to shame people, and also because it will guarantee a bunch of no-true-scottsman, "X, Y, and Z were student projects and Q was just a demo and R only panic because cargo built a debug build by default and there was an integer overflow, and M was only because I didn't provide all the required command-line arguments...".

All those things are true, but my experience, in practice, is that the overwhelming majority of rust things I have attempted to use are broken out of the gate in a way that software written in C/C++ is usually not. I'm glad to hear that not everyone has had that experience-- I did kind of wonder if my comment was going to trigger one of those things where everyone has had the same experience but no one talks about it until someone breaks the ice--, but I have also heard other people express experiences similar to mine the experience is jarring particularly because of the hyped context that rust is usually discussed in.

> still shows examples which make use of expect or unwrap,

right, or older code which is full of unwrap from top to bottom. :)

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

#87

Post by ridiculous_fish » Sun, Aug 02, 2020, 6:01 PM UTC

XMPPwocky wrote: post #31

the_duke wrote: post #13

Earlier quoted context omitted.

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.

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.

I think that is too strong. Consider this code:

    unsafe { libc::fork() };
    let v = vec![1];

This may hang or even crash (malloc in the child) but there's no sense in which the unsafe block is "incorrect." Some unsafe code has unavoidable implications for the entire program.

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

#88

Post by Animats » Sun, Aug 02, 2020, 6:06 PM UTC

doonesbury wrote: post #80

touisteur wrote: post #53

Earlier quoted context omitted.

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...

Agree!

Right. Should have said that. Often, after a check on an inner loop subscript has been hoisted, it simplifies to a tautology, like "n <= n".

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

#89

Post by Animats » Sun, Aug 02, 2020, 6:13 PM UTC

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.

The function containing the unsafe block can be called from safe code. So unsafe functionality can be exported. Said unsafe functionality might not be safe for all possible inputs. That's a classic hole, as with APIs that can be exploited.

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

#90

Post by burntsushi » Sun, Aug 02, 2020, 7:05 PM UTC

Animats wrote: post #89

burntsushi wrote: post #10

Earlier quoted context omitted.

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

The function containing the unsafe block can be called from safe code. So unsafe functionality can be exported. Said unsafe functionality might not be safe for all possible inputs. That's a classic hole, as with APIs that can be exploited.

Then that's a "function containing an unsafe block," not an "unsafe function." In any case, this is still a misunderstanding of what staticassertion said. I elaborated more here: https://news.ycombinator.com/item?id=24028359

My bigger point here is that you're misunderstanding the advocated Rust value proposition. The value proposition isn't literally "Rust will forever and always eliminate all memory safety bugs in safe Rust." That's silly and no serious person with any credibility would double down on that claim.