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

131–140 of 141 posts

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

#131

Post by gpderetta »

searealist wrote: post #129
pclmulqdq wrote: post #63

Earlier quoted context omitted.

One piece of friction that hurts here is that the C++/Rust and ARM memory models aren't the same, and the consequences of this are unintuitive - compilers and CPUs can both screw with execution ordering. People who write in C++ should technically _only_ be concerned with the C++ memory model, but x86 has let them be very lax and undisciplined with std::memory_order_relaxed. ARM has some alluring constructs that don't…

ARMv8 basically exactly mirrors the C++ memory model without any explicit memory orderings (the default on atomics being sequentially consistent).

It also added load acquires and store releases to map to the corresponding very common (as they are fast on x86) C++ primitives.

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

#132

Post by JulianMorrison »

convolvatron wrote: post #108
JulianMorrison wrote: post #89

Earlier quoted context omitted.

It's not "don't invent it". It's "be competent before you invent it, because it's hard". And if you aren't, then let someone who is do the inventing.

the best way to _get_ competent is to try so yes - invent your own synchronization primitives. please. just dont believe they are correct without being serious about trying to prove they are. and dont hold up your whole project for self-enrichment. but try to layer as much in as you can. developers these days are so productive, until they fall down and cant get up. and then they are completely useless.

Disagreed. There are some problems, and low level hardware is one of them, where you need understanding and not just experience.

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

#133

Post by destring »

anyfoo wrote: post #122
gpderetta wrote: post #50

Earlier quoted context omitted.

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

Here are my slides from back then: https://reinference.net/mp-talk.pdf You made me wonder, because I definitely remember using Peterson's Algorithm, so I went back to my slides and turns out: I first showed the problem with x86, then indeed added an MFENCE at the right place, and then showed how that was not enough for ARM. So the point back then was to show how weaker memory models can bite you with the example of x…

Damn, my knowledge of ARM and x86 memory models was limited to "x86 provides a stronger model" but that was it. So much to learn, thanks for the slides.

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

#134

Post by gpderetta »

dataangel wrote: post #91
PaulDavisThe1st wrote: post #70

Either I'm not understanding something that I thought I understood very well, or TFA's author's don't understand something that they think they understand very well. Their code is unsafe even on x86. You cannot write a single-writer, single-reader FIFO on modern processors without the use of memory barriers. Their attempt to use "volatile" instead of memory barriers is not appropriate. It could easily cause problems…

I think their point is you only need compiler barriers not actual barrier instructions on x86. volatile in practice has been the de facto way to get the effect of a compiler memory barrier for a long time even though it's not the best way to do it nowadays. The original purpose of it is literally preventing the compiler from getting rid of loads and stores and reordering them which is exactly what is needed when impl…

volatile does not work as a memory barrier neither in theory nor in practice. On gcc for example you need an explicit additional compiler barrier before a volatile store and after a volatile load to implement the expected release/acquire semantics on x86.

See [1] for example the implementation of smp_store_release and smp_load_acquire in the linux kernel (barrier() is just a compiler barrier and {READ,WRITE}_ONCE are a cast to volatile).

Volatile only prevents reordering of volatile statements (and IO), not all load and stores.

[1] https://elixir.bootlin.com/linux/latest/source/tools/arch/x8...

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

#135

Post by gpderetta »

saagarjha wrote: post #120
addaon wrote: post #117

Earlier quoted context omitted.

To draw together the two answers here to the original question. 1) Emulating an ISA includes emulating its memory model. As saagarjha says, this means that Rosetta 2 must (and does) correctly implement total store ordering. 2) There are various ways to implement this. For emulators that include a binary translation layer (that is, that translate x86 opcodes into a sequence of ARM opcodes), one route is to generate th…

TSO is a per-thread flag; it’s implemented as a write to a MSR on context switch to switch it on or off.

Right, is it POWER that has a per page TSO flag?

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

#136

Post by [deleted] »

JulianMorrison wrote: post #132
convolvatron wrote: post #108

Earlier quoted context omitted.

the best way to _get_ competent is to try so yes - invent your own synchronization primitives. please. just dont believe they are correct without being serious about trying to prove they are. and dont hold up your whole project for self-enrichment. but try to layer as much in as you can. developers these days are so productive, until they fall down and cant get up. and then they are completely useless.

Disagreed. There are some problems, and low level hardware is one of them, where you need understanding and not just experience.

[deleted]

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

#137

Post by convolvatron »

JulianMorrison wrote: post #132
convolvatron wrote: post #108

Earlier quoted context omitted.

the best way to _get_ competent is to try so yes - invent your own synchronization primitives. please. just dont believe they are correct without being serious about trying to prove they are. and dont hold up your whole project for self-enrichment. but try to layer as much in as you can. developers these days are so productive, until they fall down and cant get up. and then they are completely useless.

Disagreed. There are some problems, and low level hardware is one of them, where you need understanding and not just experience.

so what would qualify one to do this kind of work? a graduate class in parallel programming?

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

#138

Post by saagarjha »

gpderetta wrote: post #135
saagarjha wrote: post #120

Earlier quoted context omitted.

TSO is a per-thread flag; it’s implemented as a write to a MSR on context switch to switch it on or off.

Right, is it POWER that has a per page TSO flag?

I actually do not know, sadly.

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

#139

Post by yvdriess »

formerly_proven wrote: post #100
yvdriess wrote: post #58

Earlier quoted context omitted.

A Dataflow architecture ISA would. It's been tried before. But, working out the entire software stack from scratch is a moonshot.

High-performance processors are data flow processors, which infer the data flow graph from the instruction stream using Tomasulo's algorithm.

The backend is very dataflow like, yes. But, the dependencies are only tracked within a tight instruction windows, the retirement (esp. of stores) are ordered to implement the memory ordering constraints of the processor and last but not least: the ISA itself is not Dataflow.

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

#140

Post by JulianMorrison »

convolvatron wrote: post #137
JulianMorrison wrote: post #132

Earlier quoted context omitted.

Disagreed. There are some problems, and low level hardware is one of them, where you need understanding and not just experience.

so what would qualify one to do this kind of work? a graduate class in parallel programming?

Depends which thing.

- For low level hardware grovelling, you need a sufficient understanding of the workings of modern chip internals.

- For crypto, another "don't invent your own" thing, probably a specialised degree in cryptography and a lot of practical experience.

The bar is simply higher than "I have access to a programming language and think my idea would work".

Post reply on HN