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

501–510 of 517 posts

Re: There is no memory safety without thread safety

#501

Post by comex »

tptacek wrote: post #357
comex wrote: post #315

Earlier quoted context omitted.

Yeah, that’s not nearly the level of big I was thinking of. It’s not a browser or WhatsApp or Word. Admittedly, Go is popular among developers. And there are some public examples of client-side attacks targeting developers and security researchers specifically. Such attacks could hypothetically go after something like Docker. But, searching now, every single example I can find seems to either exploit a non-developer-…

We routinely do see those exploits!

Are you talking about private examples or do you have one to share?

Re: There is no memory safety without thread safety

#503

Post by tptacek »

comex wrote: post #501
tptacek wrote: post #357

Earlier quoted context omitted.

We routinely do see those exploits!

Are you talking about private examples or do you have one to share?

Sure, I mean, take for example git.

More broadly: a lot of people mouthing off about how thread safety issues make Go unsafe, but you're one of a small minority of commenters here who could just find something and POC it. How hard do you think that would be? I'd absolutely accept a controlled-environment serverside RCE.

Re: There is no memory safety without thread safety

#504

Post by BlackFly »

dontlaugh wrote: post #302
int_19h wrote: post #281

Earlier quoted context omitted.

Yes, but even so you will never see e.g. an invalid pointer value as the result of a torn memory write. Basically, no matter what you do with threads in Java, it will not segfault. TFA's point is that (safe) Rust is also like that, but achieves it by restricting all cases where a torn write could be observed through its type system instead of VM's memory model.

More specifically, Rust prevents data races.

No, rust forces you to use a mutex but nothing will prevent you from making the mutex too small and creating tearing in your own data structures by sequentially modifying things covered by mutexes so that in between acquisition of the locks you are violating invariants. The borrow checker certainly helps however, but not without cost that was finally minimized when the scoped threads api came along.

Java has a very specific memory model, so the behavior of variables across threads is quite well defined. Basic variables can tear however (a 64bit long on a 32bit architecture) without the volatile keyword and that is quite different than rust.

Re: There is no memory safety without thread safety

#505

Post by dontlaugh »

BlackFly wrote: post #504
dontlaugh wrote: post #302

Earlier quoted context omitted.

More specifically, Rust prevents data races.

No, rust forces you to use a mutex but nothing will prevent you from making the mutex too small and creating tearing in your own data structures by sequentially modifying things covered by mutexes so that in between acquisition of the locks you are violating invariants. The borrow checker certainly helps however, but not without cost that was finally minimized when the scoped threads api came along. Java has a very s…

You didn’t describe any data races.

What Rust prevents is very specific.

Re: There is no memory safety without thread safety

#506

Post by littlestymaar »

rurban wrote: post #447
littlestymaar wrote: post #432

Earlier quoted context omitted.

No, the pony model isn't better for compute tasks… Think for instance about how you'd do efficient matrix multiplication of two matrices with a million row and column, in Pony, versus how it works in languages with shared memory. You'd spend a gigantic amount of time copying data for no good reason…

Of course pony can do shared memory. How about clevering up?

Ditching the pony model to defend it is a very strange version of the mote and bailey fallacy.

Re: There is no memory safety without thread safety

#507

Post by [deleted] »

uecker wrote: post #344
SkiFire13 wrote: post #296

Earlier quoted context omitted.

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 e…

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.

[deleted]

Re: There is no memory safety without thread safety

#508

Post by foldr »

Someone wrote: post #498
foldr wrote: post #330

Earlier quoted context omitted.

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.

> If you overwrite a pointer with an integer value, then the integer is statistically unlikely to correspond to a valid memory address On 64-bit systems, and even then, it depends on the system’s memory layout (I think most integer values in programs are < 2³²)

Right. It’s unlikely both because the 64-bit value space is huge and because on most systems pointers have some of the high bytes set whereas typical integer values don’t. IIRC this combination of factors is what makes conservative GCs like BoehmGC quite effective on 64-bit architectures.

Re: There is no memory safety without thread safety

#509

Post by amluto »

comex wrote: post #502
amluto wrote: post #477

Earlier quoted context omitted.

Some exploit authors love writing up their work. For example: https://googleprojectzero.blogspot.com/2016/12/chrome-os-exp...

Not backend.

There is absolutely nothing special about backends in this regard except that it’s more likely that the attacker doesn’t have access to the code or binary.

Re: There is no memory safety without thread safety

#510

Post by kiitos »

ralfj wrote: post #390
kiitos wrote: post #194

> To see what I mean by this, consider this program written in Go, which according to Wikipedia is memory-safe: The Wikipedia definition of memory safety is not the Go definition of memory safety, and in Go programs it is the Go definition of memory safety that matters. The program in the article is obviously racy according to the Go language spec and memory model. So this is all very much tilting at windmills.

Can you point me to the Go definition of memory safety? I searched all over their website, and couldn't find any. (But also, it'd be kind of silly for every language to make up their own definition of memory safety. Then even C is memory safe, they just have to define it the right way. ;)

For the purposes of this discussion, sure: https://go.dev/ref/mem

Relevant bit for the OP is probably:

    A data race is defined as a write to a memory location happening concurrently with another read or write to that same location, unless all the accesses involved are atomic data accesses as provided by the sync/atomic package.
Which describes exactly what is happening in the OP's program:

    func repeat_get() {
        for {
            x := globalVar //
By itself this isn't a problem, these are just reads, and you don't need synchronization for concurrent reads by themself. The problem is introduced here:

    func repeat_swap() {
        var myval = 0
        for {
            globalVar = &Ptr { val: &myval } //
Just a (chef's kiss) textbook example of a data race, and a clearly unsound Go program. I don't know how or why the OP believes "this program ... [is] according to Wikipedia memory-safe" -- it very clearly is not.

But, you know, I think everyone here is basically talking past each other.

Post reply on HN