A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
1–10 of 141 posts
Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
#2Lock-free programming is really tough. There are really only a few patterns that work (e.g. Treiber stack). Trying to invent a new lock-free algorithm, as this vulnerable code demonstrates, almost always ends in tears.
Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
#3And arm-windows will (does already?) run x86 binaries with weaker memory ordering than they were written for. So this could be a real thing soon.
Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
#4And arm-windows will (does already?) run x86 binaries with weaker memory ordering than they were written for. So this could be a real thing soon.
Now I am worried. Do you have a reference please?
Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
#5And arm-windows will (does already?) run x86 binaries with weaker memory ordering than they were written for. So this could be a real thing soon.
Are you sure the translators don't insert code necessary to maintain ordering? I would be shocked if most threaded code works when you throw out the x86 memory model. Managed runtimes like .NET definitely generate code for each target designed to maintain the correct memory model.
Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
#6Heh, 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 model forgave actually start failing, in equally subtle ways.
[1] The conclusion for this particular audience was: Don't try to avoid synchronization primitives, or even invent your own. They were not system level nor high perf code programmers, so they had that luxury.
Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
#7Lock-free programming is really tough. There are really only a few patterns that work (e.g. Treiber stack). Trying to invent a new lock-free algorithm, as this vulnerable code demonstrates, almost always ends in tears.
There are tons of lock-free algorithms, both node based and array backed up. Lock-free is notoriously easier on garbage collector set-ups, of course.
Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
#8this slaps. I always see perfect blue a few places above us!
Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
#9And arm-windows will (does already?) run x86 binaries with weaker memory ordering than they were written for. So this could be a real thing soon.
Normally the code should have all the needed memory fences as if running on DEC Alpha, e.g. linux does that, and the compilers omit the unneeded ones.
Re: A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
#10And arm-windows will (does already?) run x86 binaries with weaker memory ordering than they were written for. So this could be a real thing soon.
Are you sure the translators don't insert code necessary to maintain ordering? I would be shocked if most threaded code works when you throw out the x86 memory model. Managed runtimes like .NET definitely generate code for each target designed to maintain the correct memory model.
They better do, but then, how would an automatic translator know that this is a "release semantics" atomic store operation?
Because on x86 it is, no special barriers or instructions necessary.
mov [shared_data], 1
mov [release_flag], 1