4 ms·

TSX can provide very important speedups where there aren't adversarial workloads sharing memory. Your web browser shouldn't be using it, but I think turning it

TSX can provide very important speedups where there aren't adversarial workloads sharing memory. Your web browser shouldn't be using it, but I think turning it off globally doesn't make much sense. Unlike hyperthreading use of TSX can be decided on an app to app basis. As core counts increase spinlocks and other synchronization primitives simply become too expensive. We'll need transactional hardware support eventually.

cosmiccatnap 7y ago
That's putting alot of faith in the OS and it's ability to sandbox correctly.
- loeg 7y ago
  Especially when this publication shows that sandboxing correctly isn't possible with TSX.
loeg 7y ago
It is dangerous to treat the security domain as app-to-app instead of whole-machine given the scope of vulnerability. If your TSX workload runs on dedicated machines and/or you're ok with the reduction in kernel defenses, sure, enable it. But the default should be "off." Scaling workloads does not require transactional memory and certainly doesn't require a vulnerable implementation of it. HTM might be the easiest way to scale a relatively naive algorithm, but the most scalable synchronization is none at all (or vanishingly infrequent) — and that works just fine with conventional locks and atomics (both locked instructions and memory model "atomics" such as release/acquire/seq_cst semantics).
- jdsully 7y ago
  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.

cosmiccatnap 7y ago

That's putting alot of faith in the OS and it's ability to sandbox correctly.

loeg 7y ago
Especially when this publication shows that sandboxing correctly isn't possible with TSX.

loeg 7y ago

It is dangerous to treat the security domain as app-to-app instead of whole-machine given the scope of vulnerability. If your TSX workload runs on dedicated machines and/or you're ok with the reduction in kernel defenses, sure, enable it. But the default should be "off." Scaling workloads does not require transactional memory and certainly doesn't require a vulnerable implementation of it. HTM might be the easiest way to scale a relatively naive algorithm, but the most scalable synchronization is none at all (or vanishingly infrequent) — and that works just fine with conventional locks and atomics (both locked instructions and memory model "atomics" such as release/acquire/seq_cst semantics).

jdsully 7y ago
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.