|
|
Subscribe / Log in / New account

Support for Intel's LASS

Support for Intel's LASS

Posted Jan 14, 2023 6:50 UTC (Sat) by epa (subscriber, #39769)
Parent article: Support for Intel's LASS

I think the description of speculative execution is a bit muddled. The second paragraph says that it runs with data not in the cache, guessing the value and continuing. But the third paragraph talks about actually accessing the data, and putting it into the cache. If speculative execution really were as described in the second paragraph, and never loaded anything from memory into the cache, then most cache-based side channel attacks would not be possible.


to post comments

Support for Intel's LASS

Posted Jan 14, 2023 11:00 UTC (Sat) by matthias (subscriber, #94967) [Link] (2 responses)

Yes, this is not very clear. The data in paragraph 1 is different from the data in paragraph 3. I will sketch how meltdown works as an example.
if (a != 0) {
  if ((*b & 0x1) == 0) {
    load c
  } else {
    load d
  }
}
a is 0, but it is not in the cache and the CPU speculates that a is not 0. As the speculation is mostly statistics, one can enforce this speculation. The pointer b points to non-accessible memory (e.g. kernel memory). Based on the value of *b, either c or d is loaded into the cache. Normally the access to *b would trigger a SEGFAULT, but as a is 0, the CPU detects at some point that this was all just speculation, it ignores the fault and continues as if nothing did happen.
Now one can access c and d, measure the time this takes and conclude which of the two has been loaded into the cache. This gives away one bit from *b.
So speculative execution does affect the cache. After all you can gain the most advantage if the value (c or d) is already on its way to the cache at the point of time when the value of a finally arrives at the CPU.
The data that is not in the cache and whose value is point of speculation is a. The data that discovered is (one bit of) *b, and the data that is loaded into the cache is either c or d. The presence of c or d is used to discover the value of *b.

Support for Intel's LASS

Posted Jan 15, 2023 12:11 UTC (Sun) by ballombe (subscriber, #9523) [Link] (1 responses)

Your example require b to be in the cache, yes ?
Then it computes *b, detect the fault, but still continue with load ?

Support for Intel's LASS

Posted Jan 15, 2023 13:06 UTC (Sun) by matthias (subscriber, #94967) [Link]

Yes, b and *b should both be in the cache (the pointer and the data pointed to). Then misprediction is only detected after *b is evaluated and the load of c or d is already on its way. If *b would not be in the cache, probably a would arrive before *b and the inner if would never be evaluated. But *b would be loaded and one can just repeat the whole thing with some different a that is not yet in the cache.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds