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

31–40 of 105 posts

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

#31

Post by XMPPwocky »

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.

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.

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

#32

Post by foota »

zozbot234 wrote: post #30
foota wrote: post #29

Earlier quoted context omitted.

What I really want is an integration of automated proof checking with unsafe code, allowing completely safe rust programs. Additionally, this could be extended to safe code to allow removing overhead from safety in things like bounds checks and Rc.

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 to construct the machine level operations.

With a formal semantics the proof checker just checks that the written proof (at rust level) matches with the rust code, but requires as you said an understanding of how unsafe rust interacts with the proof, whereas 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.

Perhaps the machine level could be some layer in llvm? I'm only a little familiar with compilers, and hardly at all with more complicated compiler theory, but this seems reasonable to me.

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

#33

Post by XMPPwocky »

nullc wrote: post #28
nestorD wrote: post #25

Earlier quoted context omitted.

Note that the use of the word "panic" in Rust can be a bit misleading. It is not equivalent to a segfault in C/C++ but rather to a volontarily uncaught exception, killing the application.

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…

There's also just not that much Rust software out there, and 80% of everything is crap. If you compare the best, say, C tool to do something against the best Rust tool, the odds that the Rust tool will be lower-quality are higher - the Rust tool is probably the only Rust tool written to do that, while the C tool is probably the best C tool that's survived over the years.

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

#34

Post by vinay_ys »

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.

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?

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

#36

Post by Const-me »

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.

> 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 native memory corruptions in C++, than in unsafe subset of a memory safe language. C++ has lots of runtime support for that (especially in debug builds), and many great tools, both in the compilers and external ones. Unsafe C# has none of them.

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

#37

Post by dthul »

nullc wrote: post #28
nestorD wrote: post #25

Earlier quoted context omitted.

Note that the use of the word "panic" in Rust can be a bit misleading. It is not equivalent to a segfault in C/C++ but rather to a volontarily uncaught exception, killing the application.

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 also one of the first things that are called out when an inexperienced Rust user asks for feedback on their program in the forum, so should be quite uncommon in any program which is more than a toy or prototype.

Again, not to say that you did not experience this, but just pointing out that it is definitely neither idiomatic nor usual practice.

Edit: There is indeed one point where the Rust community could do better to further reduce the number of panic-ing operations: Some time ago, it was not easy to use the error propagation operator "?" in documentation examples, so some documentation still shows examples which make use of expect or unwrap, possibly guiding inexperienced users towards a bad style. Those will hopefully vanish more or less completely in the near future.

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

#38

Post by dkersten »

nullc wrote: post #28
nestorD wrote: post #25

Earlier quoted context omitted.

Note that the use of the word "panic" in Rust can be a bit misleading. It is not equivalent to a segfault in C/C++ but rather to a volontarily uncaught exception, killing the application.

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…

A panic is superior to a segfault, because panics can (and should — if they don’t, then yes, that’s lazy) include a programmer-specified error message. A segfault just says “oops” (and a hopefully a stack trace in both cases).

I mean, yes, if a program can recover, it should, but in the case of “error and quit”, panic is an improvement over segfault.

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

#39

Post by Klasiaster »

vinay_ys wrote: post #35

Really well written article with a nice diagram that concisely explains all the memory safe/unsafe areas of a rust program.

The diagram arrows of »Only valid references«, »No dangling pointers«, and »No data races« only point to the Heap Memory but should also point to the Stack Memory. One reason is that a function can borrow a stack pointers to other functions it calls at which point for the other functions there is no difference whether they are stack or heap pointers. Valid references are relevant the same way. Other reasons are that the borrow checker prevents data races for data on the stack, and it also disallows to pass a stack pointer as return value which would be a dangling pointer.

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

#40

Post by imtringued »

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 but it's easy to take this too far and conclude that e.g. Javascript is not memory safe because browsers are written in C++ and they have to interface with the kernel which is written in C. At some point you simply need to trust that the current implementation is correct and bug free. This is also a problem with formal verification. What verifies the verification?
Post reply on HN