[codys]

One can evaluate Go using the extent of the definition from the site itself, which uses out of bounds reads and writes as a sign of memory unsafety.

Go's implementation allows torn writes for interfaces (which are 2 words in size). These torn writes allow arbitrary memory reads/writes (a superset of out of bounds reads/writes)

[llmslave2]

Has this problem (which is really a race condition problem) ever been shown to be exploitable or lead to issues?

[codys]

It sounds like you have a definition of memory safety you aren't disclosing.

Please fully provide your definition of memory safety. Not interested in trying to figure out what it is in a 20-questions-over-hn way.

[llmslave2]

The definition from the posted website seems sufficient to me.

[codys]

In that case, I can just refer back to my original comment: https://news.ycombinator.com/item?id=46388948

And then note that memorysafety.org says this (in case folks haven't read it):

> Memory safety is a property of some programming languages that prevents programmers from introducing certain types of bugs related to how memory is used.

They then provide an examine of out-of-bounds read/write. Which is the exact example I noted in my linked comment.

(Note: memorysafety.org does not provide a concrete definition of memory safety, but we get enough from what it says in this case)

The site does not require the known existence of an exploit in popular software (and does not require that _any_ exploit be possible, a bug is sufficient), merely that the language fails to block "certain types of bugs".

[llmslave2]

Can you point to a single instance of this causing an issue?

[codys]

Here's an example where a bug could exist in go due torn writes in a real program.

I found this by searching for places where folks reload there config at runtime, as they are generally a place where people forget to synchronize correctly in go.

1. A viper.OnConfigChange callback is set up to call readConfig(): https://github.com/OdyseeTeam/chainquery/blob/48c092515dea5c...

2. Inside readConfig(), we assign to a slice `twillio.RecipientList` (https://github.com/OdyseeTeam/chainquery/blob/48c092515dea5c...

3. Note that in Go, slices are objects composed of 3 words (https://go.dev/blog/slices-intro#slice-internals) And there isn't syncronization built-in over updating them. As a result, if something reads the slice while it's being updated we will mix together a data pointer & length & capacity that correspond to different real slice objects. If the length we read is from a slice that has real length 10, but the data pointer we read is from a slice with real length 1, when iterating we'll read memory out of bounds.

4. in the context of this particular program, we may send SMSs to recipients who were never in the configured list if a config change occurs at the right time. Or a segfault. Entirely unclear if reading the memory will result in reasonable behavior.

Note: I'm not familiar with this repo otherwise. This is from a quick search.