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

81–90 of 141 posts

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

#81

Post by vlovich123 »

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.

A hundred times is not that much except for really cold code paths. It’s probably in the billions if not more and I have to imagine that software level effects typically swamp HW-level effects here. That’s why you see software typically having a performance deviation no greater than ~5-10% unless you’re running microbenchmarks.

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

#82

Post by gpderetta »

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…

As noted elsethread, the code is indeed wrong even on x86, although you only need compiler fences there.

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

#83

Post by vlovich123 »

agent327 wrote: post #76
tialaramex wrote: post #54

Earlier quoted context omitted.

Yes P1152 was taken for C++ 20. The purpose of abolishing volatile isn't so much to reinforce that it's not intended for this sort of threading nonsense (indeed on Windows the MSVC guarantees mean it almost is intended for this sort of nonsense) but to make it explicit that "volatile variables" were never really a thing anyway by abolishing the volatile qualifier on variables. The thing your hardware can actually do…

>With "volatile variables" you can use compound assignment operators on the variable. What does that even mean? Nothing. It means exactly the same thing as on a normal variable, and it boggles the mind that people somehow not understand that. Given 'volatile int i', 'i++' means the exact same thing as 'i = i + 1'. Does that also not make any sense to you? If it does, can you explain why you believe they are different…

Not sure what will actually happen, but you could easily allow volatile variables with if they have extern “C” linkage for compatibility with C headers, while deprecating it elsewhere.

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

#84

Post by kloch »

vlovich123 wrote: post #79
kloch wrote: post #75

Earlier quoted context omitted.

> "volatile" does not mean what you think it means; if you're using it for anything other than interacting with hardware registers in a device driver, you're almost certainly using it incorrectly. Another "correct" use of volatile is a hack to prevent compilers from optimizing away certain code. It's pretty rare to need that and often you can just use a lower optimization level (like the usual -O2) but sometimes you…

I can’t imagine it’s an O2 vs O3 thing unless a compiler enables “fast-math” optimization to allow associativity. Neither clang nor GCC do this (neither does MSVC I think) - optimization levels never silently turn off IEEE754 floating point. I don’t know about ICC but it sounds like they stupidly enable fast math by default to try to win at benchmarks. Do you have anything to actually support this statement or did yo…

I did tests on Kahan summation recently on my macbook pro and -O3 defeated the algorithm while -O2 did not. Declaring the below variables as volatile restored error compensation with -O3.

The relevant code is:

          kahan_y=g_sample_z - kahan_c;
          kahan_t=g_sample_z_sum + kahan_y;
          kahan_c=(kahan_t - g_sample_z_sum) - kahan_y;
          g_sample_z_sum=kahan_t;
(this is in an inner loop where a new g_sample_z is calculated and then added to a running g_sample_z_sum with this snippet)

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

#85

Post by gpderetta »

vlovich123 wrote: post #79
kloch wrote: post #75

Earlier quoted context omitted.

> "volatile" does not mean what you think it means; if you're using it for anything other than interacting with hardware registers in a device driver, you're almost certainly using it incorrectly. Another "correct" use of volatile is a hack to prevent compilers from optimizing away certain code. It's pretty rare to need that and often you can just use a lower optimization level (like the usual -O2) but sometimes you…

I can’t imagine it’s an O2 vs O3 thing unless a compiler enables “fast-math” optimization to allow associativity. Neither clang nor GCC do this (neither does MSVC I think) - optimization levels never silently turn off IEEE754 floating point. I don’t know about ICC but it sounds like they stupidly enable fast math by default to try to win at benchmarks. Do you have anything to actually support this statement or did yo…

there is some amount of truth on what the parent is saying. Ages ago, when x86 only had x87 FP, gcc would program the FPU to use 80 bit precision even when dealing with doubles. The excess precision meant that GCC could not implement IEEE math correctly even without fast-math. Forcing the storing of intermediate values into memory via volatile variables was a partial solution to this problem.

MSVC configures the FPU to use 64 bit precision which means that double words fine, but it has no 80 bit long double and float still suffer from excess precision.

SSE avoid all these problems.

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

#86

Post by gpderetta »

agent327 wrote: post #76
tialaramex wrote: post #54

Earlier quoted context omitted.

Yes P1152 was taken for C++ 20. The purpose of abolishing volatile isn't so much to reinforce that it's not intended for this sort of threading nonsense (indeed on Windows the MSVC guarantees mean it almost is intended for this sort of nonsense) but to make it explicit that "volatile variables" were never really a thing anyway by abolishing the volatile qualifier on variables. The thing your hardware can actually do…

>With "volatile variables" you can use compound assignment operators on the variable. What does that even mean? Nothing. It means exactly the same thing as on a normal variable, and it boggles the mind that people somehow not understand that. Given 'volatile int i', 'i++' means the exact same thing as 'i = i + 1'. Does that also not make any sense to you? If it does, can you explain why you believe they are different…

Yes, it will likely be reverted [1] for bitwise ops, while keeping += and ++ deprecated (to save face someone would say).

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p232...

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

#87

Post by uuidgen »

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…

> "lock-free algorithms" is a misnomer, you still have synchronization,

Lock-free doesn't mean that there is no synchronization. It is a way to synchronize memory access between threads from the start. It means that there is no additional locking to protect access to the shared resource - all read access is valid, from any number of simultaneous write accesses at least one succeeds (which is not true for some other algorithms like network exponential backoff).

Even on x86 the most common instruction you use is LOCK cmpxchg.

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

#88

Post by twodai »

codeflo wrote: post #67
cesarb wrote: post #57

Earlier quoted context omitted.

Unless you're the maintainer of the parking_lot crate, you're not "inventing your own". And since parking_lot is AFAIK the second most popular implementation of mutexes and RW locks in Rust (the most popular one being obviously the one in the Rust standard library, which wraps the OS-provided lock implementations), you can assume it's well tested.

Everything about which people tell you to “not invent your own” must be invented by someone .

I guess it's more about priorities, if you want to build a web app don't reinvent the underlying protocols. If you want to build an embedded system for monitoring room temperature don't invent your own locks.

But if you want to make a lock by all means make a lock, just don't go and reinvent the chip architecture...

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

#89

Post by JulianMorrison »

codeflo wrote: post #67
cesarb wrote: post #57

Earlier quoted context omitted.

Unless you're the maintainer of the parking_lot crate, you're not "inventing your own". And since parking_lot is AFAIK the second most popular implementation of mutexes and RW locks in Rust (the most popular one being obviously the one in the Rust standard library, which wraps the OS-provided lock implementations), you can assume it's well tested.

Everything about which people tell you to “not invent your own” must be invented by someone .

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.

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

#90

Post by pornel »

codeflo wrote: post #67
cesarb wrote: post #57

Earlier quoted context omitted.

Unless you're the maintainer of the parking_lot crate, you're not "inventing your own". And since parking_lot is AFAIK the second most popular implementation of mutexes and RW locks in Rust (the most popular one being obviously the one in the Rust standard library, which wraps the OS-provided lock implementations), you can assume it's well tested.

Everything about which people tell you to “not invent your own” must be invented by someone .

You're taking a saying too literally.

People who take on task of writing such library, and develop it to the point it's a language-wide standard, usually know what they're doing (or learn on the job :)

Popularity of such library helps test it thoroughly on many platforms in various conditions, so there's a high chance the bugs will be spotted and fixed.

Post reply on HN