Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Saturday February 16 2019, @02:08PM   Printer-friendly
from the so-that-means...-we-are-screwed dept.
 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by Anonymous Coward on Saturday February 16 2019, @05:45PM

    by Anonymous Coward on Saturday February 16 2019, @05:45PM (#802106)

    You would need a "reset cache".

    The problem is that the speculative branch does things that shouldn't have been done -- like fetch data from RAM that turns out being unnecessary. Then, check to see how fast it is to access something similar from RAM -- no page fault, no delay? It much already be in cache!... simplified, but for example. The problem is: data from RAM was cached. It's now in the cache. The fixes have been to flush the cache when switching program contexts, like from kernel code to user code.

    To fix it, you would need a reset-cache -- anything that was changed in the speculative branch would have to be reset to how it was before the speculative execution took place. So, double your CPU cache. Right? You could shrink it somewhat by changed-cache-block tracking, and keeping track of which execution path changed which blocks, for all the execution paths (usually two?). Resetting anything that changed means you would trigger the same page faults, have the same latency in accessing data as if the speculative execution never happened.

    You could also have a different copy of the cache for each speculative execution branch. Or maybe L1 cache or L2 cache only. Perhaps copy-on-write, completely copying the entire working cache from the execution branch every time there's a speculative execution event.

    It's expensive. Computationally, silicon, duplication of data, it's expensive.

    Bonus: a previously undiscussed speculative execution data-disclosure issue, cache clearing. If you know a way to cause a cache conflict, then you can cause the CPU cache to be cleared of certain data. Suppose you execute a branch that would cause data to be fetched from RAM and placed in a known location in CPU cache shared with other known data, and the other branch doesn't place the data there. Then try to access the original data again -- if it page faults (has to re-fetch because cleared from cache), then speculative data disclosure. Much slower than the other versions, but regardless.

    Starting Score:    0  points
    Moderation   +3  
       Insightful=1, Interesting=2, Total=3
    Extra 'Interesting' Modifier   0  

    Total Score:   3