2 ms·

The problem TSX is attempting to address is bus traffic from those exact lock instructions you mention. These work OK for the relatively small core counts of t

The problem TSX is attempting to address is bus traffic from those exact lock instructions you mention. These work OK for the relatively small core counts of today but won't scale to hundreds of cores. TSX brings hardware supported optimistic locking and breaks the latency imposed by MESI and related protocols in use today. Of course its great if you can get away with no synchronization at all - but then you might as well just use a GPU. TSX helps with those non-trivially parallelized problems that are still best performed on a CPU.

loeg 7y ago
I explicitly mentioned memory model atomics in addition to locked instructions in an attempt to prevent getting hung up on locked atomics. I guess that didn't work. Obviously many workloads require some coordination, but often something as trivial as allocating one of a given resource per CPU is sufficient to avoid most contention even on 100s of CPU core machines. Profile; improve. The same is required with HTM. Regardless of your thoughts on HTM and scaling technology, TSX is broken from a security standpoint, which is the primary subject of the fine article. HTM != TSX.
- comex 7y ago
  I agree with your conclusion that TSX needs to be disabled. I mean, I don’t know why anyone is arguing against that, since it follows directly from this attack; the alternative is to clear the L1 cache across security boundaries, but that’s probably slower than just coping without TSX. The case for disabling TSX was somewhat weaker before this latest finding, but not that much, and the point is moot now. Though I do wonder if someone will find a different way to leak data from the same buffer that doesn’t rely on TSX. (Didn’t the original ZombieLoad paper already find some, but they were amenable to kernel-side workarounds?) I’m going to nitpick, though. > I explicitly mentioned memory model atomics in addition to locked instructions in an attempt to prevent getting hung up on locked atomics. I guess that didn't work. By “memory model atomics” do you mean atomic loads and stores rather than, say, compare-and-swap or atomic-increment? Because C++11 compare-and-swap and atomic-increment operations take a memory ordering parameter, yet they still generate the same `lock cmpxchg` and `lock inc` instructions. But the issue isn’t locks; none of those instructions actually lock the entire memory bus like in the old days (...unless you pass an unaligned address!). They lock the cache line, which causes cache line thrashing if many processors do it at the same time, and that’s the biggest source of overhead. But plain stores also lock the cache line. A compare-and-swap is more expensive than a plain store, but not that much more.

loeg 7y ago

I explicitly mentioned memory model atomics in addition to locked instructions in an attempt to prevent getting hung up on locked atomics. I guess that didn't work. Obviously many workloads require some coordination, but often something as trivial as allocating one of a given resource per CPU is sufficient to avoid most contention even on 100s of CPU core machines. Profile; improve. The same is required with HTM. Regardless of your thoughts on HTM and scaling technology, TSX is broken from a security standpoint, which is the primary subject of the fine article. HTM != TSX.

comex 7y ago
I agree with your conclusion that TSX needs to be disabled. I mean, I don’t know why anyone is arguing against that, since it follows directly from this attack; the alternative is to clear the L1 cache across security boundaries, but that’s probably slower than just coping without TSX. The case for disabling TSX was somewhat weaker before this latest finding, but not that much, and the point is moot now. Though I do wonder if someone will find a different way to leak data from the same buffer that doesn’t rely on TSX. (Didn’t the original ZombieLoad paper already find some, but they were amenable to kernel-side workarounds?) I’m going to nitpick, though. > I explicitly mentioned memory model atomics in addition to locked instructions in an attempt to prevent getting hung up on locked atomics. I guess that didn't work. By “memory model atomics” do you mean atomic loads and stores rather than, say, compare-and-swap or atomic-increment? Because C++11 compare-and-swap and atomic-increment operations take a memory ordering parameter, yet they still generate the same `lock cmpxchg` and `lock inc` instructions. But the issue isn’t locks; none of those instructions actually lock the entire memory bus like in the old days (...unless you pass an unaligned address!). They lock the cache line, which causes cache line thrashing if many processors do it at the same time, and that’s the biggest source of overhead. But plain stores also lock the cache line. A compare-and-swap is more expensive than a plain store, but not that much more.