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

321–330 of 517 posts

Re: There is no memory safety without thread safety

#321

Post by Ygg2 »

Wowfunhappy wrote: post #237
Ygg2 wrote: post #199

Earlier quoted context omitted.

> People talk as if "memory safety" was a PLT axiom. It's not; it's a software security term of art. It's been in usage for PLT for at least twenty years[1]. You are at least two decades late to the party. Software is memory-safe if (a) it never references a memory location outside the address space allocated by or that entity, and (b) it never executes intstruction outside code area created by the compiler and linke…

...by that definition, can a C program be memory safe as long as it doesn't have any relevant bugs, despite the choice of language? (I realize that in practice, most people are not aware of every bug that exists in their program.)

Sure. It can be. In the same way, a C program can be provably correct. I.e., for all inputs it doesn't exhibit unexpected behavior. Memory safety and correctness are properties of the program being executed.

But a memory-safe program != memory safe language. Memory safe language helps you maintain memory-safety by reducing the chances to cause memory unsafety.

Re: There is no memory safety without thread safety

#322

Post by Someone »

foldr wrote: post #317
elcritch wrote: post #313

Earlier quoted context omitted.

Segfault sounds better than running with inconsistent data.

The inconsistent data thing could happen in Go too. A segfault is not guaranteed, it’s just one of the more likely possibilities.

> A segfault is not guaranteed, it’s just one of the more likely possibilities.

Is it? It will depend on the code, but my gut feeling is that you typically would get a few (if not lot of) unnoticed non-segfaulting issues before you get the segfaulting one that tells you straight in your face that you have a problem.

Re: There is no memory safety without thread safety

#323

Post by tsimionescu »

dev_l1x_be wrote: post #306
tsimionescu wrote: post #288

Earlier quoted context omitted.

I don't think that's the (only) reason Go became popular. The huge thing about Go is the runtime: it's the only language runtime available today, at least in any language with a large org behind it, that offers (a) GC, (b) fast start-up time, (c) static types, (d) fast execution, and (e) multi-threading. This is a killer combination for any team looking to write code for auto-scalable microservices, to run for exampl…

F# does that too. > .NET has similar problems s/has/had/ https://blog.washi.dev/posts/tinysharp/ The issue is that some people still fighting against the concepts ML family languages (primarily SML) introduced. Go implemented go routines and channels from CSP ( https://en.wikipedia.org/wiki/Communicating_sequential_proce... ) but dragged a lot on influence from C (understandable) into the language. I think Rust opted…

Not sure what you mean about F# - being a CLR language, it has the same runtime issues as C# (and IronPython, managed C++, etc).

The article you quote is a toy example - if you write a C# or F# web API server, you'll see that it takes up way more space than a Go one with similar functionality (and has way higher memory overhead as well). A Go API web server is maybe 10MB on disk, with no dependencies (that is, you can run it perfectly in a container that is defined as `FROM scratch; COPY my-go-exec /my-go-exec `). The equivalent Java or .NET container is somewhere around 2-400MB at the minimum.

As for the syntax and constructs, I don't care so much. If OCaml or SML had comparable support and a comparable ecosystem to Go, I'd bet plenty of people would have chosen them instead.

Re: There is no memory safety without thread safety

#324

Post by nicoburns »

tptacek wrote: post #245
moefh wrote: post #240

Earlier quoted context omitted.

I agree that there are two groups here talking past each other. I think it would help a lot to clarify this: > the issue here is that the "Rust and Java sense" of memory safety is not the actual meaning of the term So what is the actual meaning? Is it simply "there are no cases of actual exploited bugs in the wild"? Because in another comment you wrote: > a term of art was created to describe something complicated; i…

It's a contrived type confusion bug. It reads 42h because that address is hardcoded, and it does something that ordinary code doesn't do. If you were engaged to do a software security assessment for an established firm that used Go (or Python, or any of the other mainstream languages that do shared-memory concurrency and don't have Rust's type system), and you said "this code is memory-unsafe", showing them this exam…

You are however replying to thread where a Dropbox engineer calls it "a right of passage" to introduce such bugs to their codebase. Which suggests that it is by no means unheard of for these problems to crop up in real-world code.

Re: There is no memory safety without thread safety

#325

Post by nosefrog »

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…

Hi Chad!

Re: There is no memory safety without thread safety

#326

Post by CJefferson »

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…

Before Rust, I'd reached the personal conclusion that large-scale thread-safe software was almost impossible -- certainly it required the highest levels of software engineering. Multi-process code was a much more reasonable option for mere mortals.

Rust on the other hand solves that. There is code you can't write easily in Rust, but just yesterday I took a rust iteration, changed 'iter()' to 'par_iter()', and given it compiled I had high confidence it was going to work (which it did).

Re: There is no memory safety without thread safety

#327

Post by rurban »

littlestymaar wrote: post #202
fmajid wrote: post #200

Earlier quoted context omitted.

And yet it ignored the primary lesson of Erlang: no shared memory access whatsoever, which is what makes it so robust.

Because the other teams members (IIRC brson and pcwalton) wanted Rust to be as performant as C++, which means you must have a way to have shared memory.

Which was the ultimate failure of Rust, because as Pony benchmarks have shown, you get safety and speed by proper security and architecture. Rust just survived by lying about the its safeties.

What kills performance are not memory copies, but locks. Parallel nonblocking IO and a non POSIX stdlib will bring you far away from C++ or Rust performance.

Re: There is no memory safety without thread safety

#328

Post by jacquesm »

tptacek wrote: post #245
moefh wrote: post #240

Earlier quoted context omitted.

I agree that there are two groups here talking past each other. I think it would help a lot to clarify this: > the issue here is that the "Rust and Java sense" of memory safety is not the actual meaning of the term So what is the actual meaning? Is it simply "there are no cases of actual exploited bugs in the wild"? Because in another comment you wrote: > a term of art was created to describe something complicated; i…

It's a contrived type confusion bug. It reads 42h because that address is hardcoded, and it does something that ordinary code doesn't do. If you were engaged to do a software security assessment for an established firm that used Go (or Python, or any of the other mainstream languages that do shared-memory concurrency and don't have Rust's type system), and you said "this code is memory-unsafe", showing them this exam…

My own takeaway after looking at corporate codebases for four decades is that the state of the art in software development at banks, governments, insurance companies, airlines, health care and so on is such that I long for the time before the internet.

Sure, those mainframes from the 80's weren't bullet proof either. But you first had to get to them. And even if the data traveled in plain text on leased lines (point-to-point but not actually point-to-point (that would require a lot of digging), no multiplexing) you had to physically move to the country where they were located to eavesdrop on them, and injecting data into the stream was a much harder problem.

Re: There is no memory safety without thread safety

#329

Post by elktown »

tptacek wrote: post #4

This is a canard. What's happening here, as happens so often in other situations, is that a term of art was created to describe something complicated; in this case, "memory safety", to describe the property of programming languages that don't admit to memory corruption vulnerabilities, such as stack and heap overflows, use-after-frees, and type confusions. Later, people uninvolved with the popularization of the term…

The older I get the more I just see these kinds of threads like I see politics: Exaggerate your "opponents" weaknesses, underplay/ignore its strengths and so on. So if something no matter how disproportionate can be construed to be, or be associate with, a current zeitgeist with a negative sentiment, it's an opportunity to gain ground.

I really don't understand why people get so obsessed with their tools that it turns into a political battleground. It's a means to an end. Not the end itself.

Re: There is no memory safety without thread safety

#330

Post by foldr »

Someone wrote: post #322
foldr wrote: post #317

Earlier quoted context omitted.

The inconsistent data thing could happen in Go too. A segfault is not guaranteed, it’s just one of the more likely possibilities.

> A segfault is not guaranteed, it’s just one of the more likely possibilities. Is it? It will depend on the code, but my gut feeling is that you typically would get a few (if not lot of) unnoticed non-segfaulting issues before you get the segfaulting one that tells you straight in your face that you have a problem.

It probably depends on how exactly the corruption happens. If you overwrite a pointer with an integer value, then the integer is statistically unlikely to correspond to a valid memory address. On the other hand, if you overwrite a pointer with a pointer, or an integer with an integer, all bets are off.
Post reply on HN