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

▲

ralfj 4 days ago | parent | next [-]

(EDIT: removed the first part since I realized you were replying to some comment further up, not my example.)

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

I am not sure I agree with that (the concept of memory-safe languages looong predates Rust), but you can just define a memory-safe language as one where all conforming implementations are memory-safe -- making it a feature of the language itself, not just a feature of a particular implementation.

	▲	uecker 4 days ago \| parent [-]
		I am not really saying the term is not useful, the idea that it is the only legitimate way of memory safety is what I am questioning.

▲

SkiFire13 5 days ago | parent | prev [-]

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.

▲

uecker 4 days ago | parent [-]

Whether you can a segfault if you access an out-of-bounds address or not is part of the language implementation. An implementation that guarantees a segfault for out-of-bounds accesses is memory safe.

▲

zozbot234 4 days ago | parent | next [-]

You can't really guarantee that all out-of-bounds accesses will segfault, because memory protection mechanisms are not that granular. (And actual memory segmentation, that did have the required granularity, has fallen out of use - though CHERI is an attempt to revive it.) That's why a segfault is treated as something to be avoided altogether, not as a reliable error mechanism.

What you can say though (and the point I made upthread) is that if a language manages to provably never segfault, then it must have some sort of true language-enforced safety because the difference between segfaulting or not is really just a matter of granularity.

▲

uecker 4 days ago | parent [-]

How granular the memory protection mechanism is is part of the implementation.

▲

zozbot234 4 days ago | parent [-]

It's part of the broader system, not the language implementation. And in practice, systems that achieve this are not in common use.

	▲	uecker 4 days ago \| parent [-]
		You are using a narrower definition than me. The language implementation builds on the functionality of the a larger system. An implementation can utilize the functionality of the overall system and close the loopholes. For example, using sanitizer you can turn out-of-bounds accesses to arrays into traps. This is not a segmentation fault but SIGILL, but it also builds on the trapping mechanism to achieve bounds safety (if you limit yourself to arrays).

▲

2 days ago | parent | prev [-]

[deleted]