Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There is no memory safety without thread safety

ralfj.de

Post reply on HN
Print view View original

291–300 of 517 posts

Re: There is no memory safety without thread safety

#291

Post by uecker »

sapiogram wrote: post #221
jlouis wrote: post #138

Earlier quoted context omitted.

The definition has to do with certain classes of spatial and temporal memory errors. Ie., the ability to access memory outside the bounds of an array would be an example of a spatial memory error. Use-after-free would be an example of a temporal one. The violation occurs if the program keeps running after having violated a memory safety property. If the program terminates, then it can still be memory safe in the defi…

> The violation occurs if the program keeps running after having violated a memory safety property. If the program terminates, then it can still be memory safe in the definition. I don't know what you're trying to say here. C would also be memory-safe if the program just simply stopped after violating memory safety, but it doesn't necessarily do that, so it's not memory safe. And neither is Go.

The point is that a segfault is not an indication for memory unsafety. It is the opposite: The OS stops some unsafe access. The problem with C implementations is that it often comes to late and the segfault does not stop a prior unsafe read or write. But this is also an implementation property, you can implement C in a memory safe way as many have shown. Rust has, unfortunately, changed the narrative so that people now believe memory safety is a property of the language, when it is one of the implementation. (there are, of course, language properties that make it harder to implement C in a memory safe way without sacrificing performance and/or breaking ABI).

Re: There is no memory safety without thread safety

#292

Post by SkiFire13 »

tptacek wrote: post #160
sophacles wrote: post #105

Earlier quoted context omitted.

I think your security background is coloring your perception of the term memory safety. Specifically the requirement that the various issues lead to exploitation. These issues can lead to many other issues that are not vulnerability in the security sense, e.g. data corruption, incorrect (but not insecure) behavior, performance issues, and more. I don't think any of those were ever dismissed or excluded from memory sa…

"Memory safety" is a security term, not a PLT term.

That's a statement without source and even if it was widely accepted as true it doesn't imply the fact that something needs to be exploitable to be considered a security issue. We are full of CVEs without a known way to be exploited.

Re: There is no memory safety without thread safety

#293

Post by SkiFire13 »

phire wrote: post #269
codys wrote: post #256

Earlier quoted context omitted.

That seems contrasted by Rob Pike's statement in 2012 in the linked presentation being one of the places where it's called "not purely memory safe". That would have been early, and Go is not called memory safe then. It seems like calling Go memory safe is a more recent thing rather than a historical thing.

Keep in mind that the 2012 presentations dates to 10 months after Rust's first release, and its version of "Memory Safety" was collecting quite a bit of attention. I'd argue the definition was already changing by this point. It's also possible that Go was already discovering their version of "Memory Safety" just wasn't safe enough. If you go back to the original 2009 announcement talk, "Memory Safety" is listed as an…

> Rust's first release, and its version of "Memory Safety" was collecting quite a bit of attention

Note that this was not Rust's first stable release, but it's first public release. At the time it was still changing a lot and still had "garbage collected" types.

Re: There is no memory safety without thread safety

#294

Post by noisem4ker »

nine_k wrote: post #233
potato-peeler wrote: post #136

Earlier quoted context omitted.

I am curious. Generally basic structures like map are not thread safe and care has to be taken while modifying it. This is pretty well documented in go spec. In your case in dropbox, what was essentially going on?

In Java, there are separate synchronized collections, because acquiring a lock takes time. Normally one uses thread-unsafe collections. Java also gives a very ergonomic way to run any fragment under a lock (the `synchronized` operator). Rust avoids all this entirely, by using its type system.

Golang has a synchronized map:

https://pkg.go.dev/sync#Map

Re: There is no memory safety without thread safety

#295

Post by jamil7 »

RetpolineDrama wrote: post #134
junebash wrote: post #71

Earlier quoted context omitted.

Swift is in the process of fixing this, but it’s a slow and painful transition; there’s an awful lot of unsafe code in the wild that wasn’t unsafe until recently.

Swift 6 is only painful if you wrote a ton of terrible Swift 5, and even then Swift 5 has had modes where you could gracefully adopt the Swift 6 safety mechanisms for a long time (years?) ~130k LoC Swift app was converted from 5 -> 6 for us in about 3 days.

Yes and no, our app is considerably larger than 130k LoC. While we’ve migrated some modules there are some parts that do a lot of multithreaded work that we probably will never migrate because they’d need to essentially be rewritten and the tradeoff isn’t really worth it for us.

Re: There is no memory safety without thread safety

#296

Post by SkiFire13 »

uecker wrote: post #291
sapiogram wrote: post #221

Earlier quoted context omitted.

> The violation occurs if the program keeps running after having violated a memory safety property. If the program terminates, then it can still be memory safe in the definition. I don't know what you're trying to say here. C would also be memory-safe if the program just simply stopped after violating memory safety, but it doesn't necessarily do that, so it's not memory safe. And neither is Go.

The point is that a segfault is not an indication for memory unsafety. It is the opposite: The OS stops some unsafe access. The problem with C implementations is that it often comes to late and the segfault does not stop a prior unsafe read or write. But this is also an implementation property, you can implement C in a memory safe way as many have shown. Rust has, unfortunately, changed the narrative so that people n…

The segfault seen here is not a property of the language implementation, it's just a consequence of the address chosen by the attacker: 42. If you replicated this code in C you would get the same result, and if you used an address pointing to mapped memory in Go then the program would continue executing like in similar exploits in C.

The only reason this isn't a more critical issue is because data races are hard to exploit and there aren't lot of concurrent Go programs/system libraries that accept lot of attacker controlled inputs.

Re: There is no memory safety without thread safety

#297

Post by SkiFire13 »

Thaxll wrote: post #205
Sesse__ wrote: post #108

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Argument_from_authority

So NSA does not have the relevant authority to qualify a language as memory safe, is it what you're saying? The document is backed by foreign government as well. https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE...

> NSA does not have the relevant authority

You did not even read the link the parent comment provided and are continuing with the same flawed argument.

Re: There is no memory safety without thread safety

#299

Post by tapirl »

chadaustin wrote: post #62

Every time this conversation comes up, I'm reminded of my team at Dropbox, where it was a rite of passage for new engineers to introduce a segfault in our Go server by not synchronizing writes to a data structure. Swift has (had?) the same issue and I had to write a program to illustrate that Swift is (was?) perfectly happy to segfault under shared access to data structures. Go has never been memory-safe (in the Rust…

Listens your team had not sufficient review capacity at that time.

Re: There is no memory safety without thread safety

#300

Post by phire »

SkiFire13 wrote: post #293
phire wrote: post #269

Earlier quoted context omitted.

Keep in mind that the 2012 presentations dates to 10 months after Rust's first release, and its version of "Memory Safety" was collecting quite a bit of attention. I'd argue the definition was already changing by this point. It's also possible that Go was already discovering their version of "Memory Safety" just wasn't safe enough. If you go back to the original 2009 announcement talk, "Memory Safety" is listed as an…

> Rust's first release, and its version of "Memory Safety" was collecting quite a bit of attention Note that this was not Rust's first stable release, but it's first public release. At the time it was still changing a lot and still had "garbage collected" types.

Yeah, it was the 0.1 release. I can't remember exactly when Rust entered the general "programming language discourse" on hackernews and /r/programming, but it was somewhere around here. I'm sure the people behind Go would have known about it by this point in time.

And while rust did have optional "garbage collected pointers", it's important to point out that it is not a garbage collected language. The ownership system and borrow checker were very much front-and-centre for the 0.1 release, it was what everyone was talking about.

Actually, my memory is that while the language had syntax to declare garbage collected pointers, it wasn't actually hooked up to a proper garbage collector. It was always more of a "we are reserving the syntax and we will hook it up when needed", and it turns out the ownership system was powerful enough that it was never needed.

Post reply on HN