TR Forums

Lazy FP state restore leaks state, including potentially your crypto keys:

https://www.intel.com/content/www/us/en ... 00145.html

https://twitter.com/cperciva/status/1007010583244230656

So far Intel only, not AMD.

Guess I need to wait a bit longer to build a new PC:
https://techreport.com/discussion/33699 ... 01#1080001

Compared to Meltdown and Spectre, this one is a non-issue, as most modern OSs (Windows and Linux 4.9 and later) already use Eager FP state save/restore anyway. I wouldn't let this one hold off a purchase.

Lazy FP save/restore comes from an age of separate Math Co-processor chips where most of the overhead was simply transferring data between the CPU, FPU and RAM. Especially since XSAVEOPT which does optimizations in hardware, Eager FP is now the norm from what I understand.

And now TLBleed which is hyperthreading rather than speculative execution.

notfred wrote:

And now TLBleed which is hyperthreading rather than speculative execution.

1. Not that worried about the real-world effectiveness of TBleed from what we've seen so far. It requires highly controlled circumstances to be effective.
2. If you are that worried about TBleed then expect to turn off hyperthreading on every chip that's got it because everybody that does SMT is also using translation lookaside buffers. So that's RyZen too as a practical matter and the more niche Power systems, even the Cavium ARM "server" chips that heavily rely on SMT too.

Agreed. I'd just like them to stop discovering new ways in which the processors are vulnerable and make something that isn't.

chuckula wrote:

notfred wrote:

And now TLBleed which is hyperthreading rather than speculative execution.

1. Not that worried about the real-world effectiveness of TBleed from what we've seen so far. It requires highly controlled circumstances to be effective.
2. If you are that worried about TBleed then expect to turn off hyperthreading on every chip that's got it because everybody that does SMT is also using translation lookaside buffers. So that's RyZen too as a practical matter and the more niche Power systems, even the Cavium ARM "server" chips that heavily rely on SMT too.

Plenty of chips without SMT that have a TLB, it dates back to the introduction of a virtual address space.
Therefore, I don't think the problem can be reduced to a statement along the lines of:
if TLB = present then
TLBleed = very yes

techguy wrote:

chuckula wrote:

notfred wrote:

And now TLBleed which is hyperthreading rather than speculative execution.

1. Not that worried about the real-world effectiveness of TBleed from what we've seen so far. It requires highly controlled circumstances to be effective.
2. If you are that worried about TBleed then expect to turn off hyperthreading on every chip that's got it because everybody that does SMT is also using translation lookaside buffers. So that's RyZen too as a practical matter and the more niche Power systems, even the Cavium ARM "server" chips that heavily rely on SMT too.

Plenty of chips without SMT that have a TLB, it dates back to the introduction of a virtual address space.
Therefore, I don't think the problem can be reduced to a statement along the lines of:
if TLB = present then
TLBleed = very yes

TLBleed specifically requires a combination of SMT + interactions with TLB to work. Otherwise the headline of the article would be about translation lookaside buffers, which basically all modern chips have, and not about "hyperthreading" or SMT that most high-performance chips have but are not common on things like smartphone chips.

The TLB itself could have bugs, but that's only part of this latest leak that, once again, requires a very high level of control over the chip to pull off successfully.

Yes, the point is that SMT gives you enough influence over and/or ability to examine the effects of the other thread simultaneously executing on the same core to use the TLB as a side channel. If you're executing on a different core, then you're not sharing the TLB with the other thread and the side channel doesn't exist. If you're executing on the same core but SMT is disabled, then the CPU resources are getting timesliced over a much longer time interval (order of milliseconds instead of nanoseconds), and therefore can't influence or examine the TLB states with enough temporal precision for an effective attack.