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

Memory Safety

memorysafety.org

Post reply on HN
Print view View original

21–30 of 157 posts

Re: Memory Safety

#21

Post by lomase »

K0nserv wrote: post #11
websiteapi wrote: post #3

Earlier quoted context omitted.

is go not memory safe? other than unsafe and other contrived goroutine scenarios, isn't it? I'm actually really curious - I've been writing go for just a couple years now and my understanding is the only ways for it to be unsafe are the two scenarios I described earlier.

Changes to multi-word pointers can cause UB due to race conditions in Go because only changes at the word level are atomic. See: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Does Rust not have race conditions?

Re: Memory Safety

#23

Post by Dylan16807 »

lomase wrote: post #21
K0nserv wrote: post #11

Earlier quoted context omitted.

Changes to multi-word pointers can cause UB due to race conditions in Go because only changes at the word level are atomic. See: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Does Rust not have race conditions?

When talking about the kind that lead to torn memory writes, no it doesn't have those. To share between threads you need to go through atomics or mutexes or other protection methods.

Re: Memory Safety

#24

Post by steveklabnik »

lomase wrote: post #21
K0nserv wrote: post #11

Earlier quoted context omitted.

Changes to multi-word pointers can cause UB due to race conditions in Go because only changes at the word level are atomic. See: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Does Rust not have race conditions?

Rust prevents data races, but not race conditions.

Re: Memory Safety

#25

Post by tekne »

lomase wrote: post #21
K0nserv wrote: post #11

Earlier quoted context omitted.

Changes to multi-word pointers can cause UB due to race conditions in Go because only changes at the word level are atomic. See: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Does Rust not have race conditions?

One of Rust's core guarantees is that a race condition in safe code will never cause UB. It might return a nondeterministic result, but that result will be safe and well-typed (for example, if it's a Vec, it will be a valid Vec that will behave as expected and, once you have a unique reference, is guaranteed not to change out from under you).

Re: Memory Safety

#26

Post by [deleted] »

sealeck wrote: post #19
squirrellous wrote: post #18

[flagged]

This is a bit like saying everyone would be a bit less jaded if the plane staying in the air wasn't hung over the Boeing 737 MAX 8 designer's heads by certain communities and used as an existential threat to the company.

[deleted]

Re: Memory Safety

#27

Post by Yoric »

websiteapi wrote: post #12
muricula wrote: post #10

Earlier quoted context omitted.

Usually people are talking about race conditions. When you say contrived you're thinking races conditions are difficult to win and unrealistic but attackers who have a lot of money on the line spend the time to win all sorts of wild race conditions consistently.

is there actually a programming language that makes race conditions impossible (I am not being facetious, I actually do not know)? if the existence of races makes a language unsafe, then aren't all languages unsafe?

It's not that race conditions are generally memory-unsafe. The same race conditions would not be memory-unsafe in, say, Java or Python.

Go has a memory model that basically guarantees that the language is memory-safe except with a few marked "unsafe" functions or in case of race conditions involving interfaces or arrays. It's pretty easy to come up with an example of such a race condition that will cause reads or writes from/to unpredictable memory addresses. I imagine it's quite feasible to turn this into reads or writes from/to crafted memory addresses, which would be a mean to defeat pretty much any security measure implemented in the language.

The Rust community caters to people who are a bit obsessive about safety (including myself) and Rust developers tend to consider this a bug in the design of the Go language (there are a few, albeit much harder to achieve, issues that are vaguely comparable in Rust and they are considered bugs in the current design of Rust). The Go community tends to attract people who are more interested in shipping than in guarantees, and Go developers who are aware of this issue tend not care and assume that this is never going to happen in practice (which may or may not be true, I haven't checked).

Re: Memory Safety

#28

Post by awesome_dude »

websiteapi wrote: post #12
muricula wrote: post #10

Earlier quoted context omitted.

Usually people are talking about race conditions. When you say contrived you're thinking races conditions are difficult to win and unrealistic but attackers who have a lot of money on the line spend the time to win all sorts of wild race conditions consistently.

is there actually a programming language that makes race conditions impossible (I am not being facetious, I actually do not know)? if the existence of races makes a language unsafe, then aren't all languages unsafe?

> is there actually a programming language that makes race conditions impossible

To my knowledge, no.

> if the existence of races makes a language unsafe, then aren't all languages unsafe?

Are we talking about "data races" or "race conditions" One can lead to the other, but race conditions are a much bigger set.

AIUI It's impossible for any language level controls to prevent any and all race conditions, because some are happening outside of the binary/process/computer.

Data races, OTOH are almost trivial to protect against - a contestable thing must have a guard that ensures a writer has exclusive access to that thing for the duration of the write.

Some languages do this with mutually exclusive locks (mutex/semaphore/go channels), some languages/paradigms do this by never having shareable objects (Functional Programming/Pass by Value), and some (Rust) are doing this with the compile time checks and firm rules on a single writer.

Edit: Never having shareable objects should really be "never allowing an outside thread/coroutine/process/whatever mutate your copy of an object" meaning that an object is immutable to them, and they have to have a copy that they can mutate to their heart's content. They have to communicate any changes back, and then you choose whether to integrate those changes, or not

Re: Memory Safety

#29

Post by i_am_a_peasant »

websiteapi wrote: post #12
muricula wrote: post #10

Earlier quoted context omitted.

Usually people are talking about race conditions. When you say contrived you're thinking races conditions are difficult to win and unrealistic but attackers who have a lot of money on the line spend the time to win all sorts of wild race conditions consistently.

is there actually a programming language that makes race conditions impossible (I am not being facetious, I actually do not know)? if the existence of races makes a language unsafe, then aren't all languages unsafe?

isn’t that the point of languages that have first class actor models something something?
Post reply on HN