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

A bug that doesn’t exist on x86: Exploiting an ARM-only race condition

github.com

Post reply on HN
Print view View original

41–50 of 141 posts

Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition

#41

Post by [deleted] »

gpderetta wrote: post #35
xxs wrote: post #34

Earlier quoted context omitted.

emulator would have a zero issue, if it's a direct transfer for assembly (not an emulator), it'd need either hardware support - e.g. apple chips, or memory barriers. The differences between arm and x86 are known for 15y+, there is nothing new about it. Also concurrency support is one of the major benefits of languages with proper memory model - java started it with JMM[0] [0]: https://www.cs.umd.edu/~pugh/java/memory…

Any emulator that wants to be remotely performance competitive will do dynamic translation (i.e JIT). In fact ahead-of-time translation is not really feasible. Memory models and JVM are not really relevant when discussing running binaries for a different architecture.

[deleted]

Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition

#42

Post by tsimionescu »

gpderetta wrote: post #24
my123 wrote: post #12

Earlier quoted context omitted.

It’s pessimistic and converts over a lot of memory accesses to RCpc or atomics. (on ARMv8.0 where you don’t have those, barriers are used more) TSO pessimization is the only way to make the thing work at a translation time cost that isn’t too high.

Or you support TSO directly on your cpu like Apple does on M1.

Sure, but Windows on ARM has to run on many ARM processors, not a specific one designed by MS. They could detect if the processor has non-standard TSO support and use that when running an x86 app, but they still have to do something to run the x86 app on a standard ARM processor.

Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition

#43

Post by xxs »

gpderetta wrote: post #35
xxs wrote: post #34

Earlier quoted context omitted.

emulator would have a zero issue, if it's a direct transfer for assembly (not an emulator), it'd need either hardware support - e.g. apple chips, or memory barriers. The differences between arm and x86 are known for 15y+, there is nothing new about it. Also concurrency support is one of the major benefits of languages with proper memory model - java started it with JMM[0] [0]: https://www.cs.umd.edu/~pugh/java/memory…

Any emulator that wants to be remotely performance competitive will do dynamic translation (i.e JIT). In fact ahead-of-time translation is not really feasible. Memory models and JVM are not really relevant when discussing running binaries for a different architecture.

The memory models are relevant as the translation/JIT/whatever has to take them in consideration. TSO is well known and it's also well known how arm weaker memory model needs memory barriers to emulate TSO.

If there is a JIT I'd expect to be able to add a read barriers, on memory location allocated by another thread - incl. allocating bits in the pointers and masking them off on each dereference. If any block appears to be shared - the code that allocated it would need to be recompiled with memory store-store barriers; the reading part would need load-load and so on. There are quite a few ways to deal with the case, aside the obvious - make the hardware compatible.

If in end it's not an easy feat to make up for the stronger memory model correctness, yet correctness should be a prime goal of an 'emulator'

Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition

#44

Post by mmwelt »

amelius wrote: post #36

Does the race condition exist when emulating x86 on Apple M1?

Apple added hardware support for x86 memory semantics.

https://news.ycombinator.com/item?id=28731534

https://mobile.twitter.com/ErrataRob/status/1331735383193903...

Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition

#46

Post by secondcoming »

gpderetta wrote: post #35
xxs wrote: post #34

Earlier quoted context omitted.

emulator would have a zero issue, if it's a direct transfer for assembly (not an emulator), it'd need either hardware support - e.g. apple chips, or memory barriers. The differences between arm and x86 are known for 15y+, there is nothing new about it. Also concurrency support is one of the major benefits of languages with proper memory model - java started it with JMM[0] [0]: https://www.cs.umd.edu/~pugh/java/memory…

Any emulator that wants to be remotely performance competitive will do dynamic translation (i.e JIT). In fact ahead-of-time translation is not really feasible. Memory models and JVM are not really relevant when discussing running binaries for a different architecture.

Doesn't the JVM define its own memory model?

Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition

#47

Post by krylon »

silisili wrote: post #22

> Nowadays, high-performance processors, like those found in desktops, servers, and phones, are massively out-of-order to exploit instruction-level parallelism as much as possible. They perform all sorts of tricks to improve performance. Relevant quote from Jim Keller: You run this program a hundred times, it never runs the same way twice. Ever.

Heraclitus, mumbling into his beard: "Told you so!"

SCNR

Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition

#48

Post by dooglius »

newpavlov wrote: post #23
beebmam wrote: post #21

Like quantum physics, memory ordering is deeply unintuitive (on platforms like ARM). Unlike quantum physics, which is an unfortunate immutable fact of the universe, we got ourselves into this mess and we have no one to blame but ourselves for it. I'm only somewhat joking. People need to understand these memory models if they intend on writing atomic operations in their software, even if they aren't currently targetin…

Memory ordering gets somewhat easier after you understand that flat memory shared by execution units is a leaky abstraction desperately patched over decades by layer and layers of hardware and software. Memory ordering is one way to represent message passing and synchronization between different cores and RAM. This why I think that "lock-free algorithms" is a misnomer, you still have synchronization, but you simply r…

Hardware synchronization has better properties than software locks: it can't deadlock, is reentrant, won't get screwed up by a process holding a lock dying, and is (supposedly) guaranteed to complete in bounded time. I don't think it's unreasonable that the definition of lock-free ("guaranteed system-wide progress") focuses on the high-level behavior of typical software locks even if it ends up calling things that are still locks in some sense "lock-free".

Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition

#49

Post by gpderetta »

secondcoming wrote: post #46
gpderetta wrote: post #35

Earlier quoted context omitted.

Any emulator that wants to be remotely performance competitive will do dynamic translation (i.e JIT). In fact ahead-of-time translation is not really feasible. Memory models and JVM are not really relevant when discussing running binaries for a different architecture.

Doesn't the JVM define its own memory model?

Sure, but how's that relevant when discussing running x86 binaries on ARM?

Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition

#50

Post by gpderetta »

anyfoo wrote: post #6

Heh, 10 years ago I gave a presentation about how easy folks used to x86 can trip up when dealing with ARM's weaker memory model. My demonstration then was with a naive implementation of Peterson's algorithm.[1] I have a feeling that we will see a sharp rise of stories like this, now that ARM finds itself in more places which were previously mostly occupied by x86, and all the subtle race conditions that x86's memory…

But Peterson's algorithm requires explicit memory barriers even on x86, it doesn't seem the best example to show the difference.
Post reply on HN