TimingArray is a new API and implementation for making it easy to induce
and measure cache timing side-channels.
Differences from CacheSideChannel:
TimingArray computes its own threshold for recognizing when a memory
read came from cache, so callers don't need to induce their own "known
cached" value. That means no more AddHitAnd... variant and less
disruption caused by the "look for cached read" action.
The threshold is computed using a pretty simple approach that only looks
at cached reads.
TimingArray spreads elements across pages and cache lines, improving
cache use and therefore side-channel signal.
Elements are always accessed in permuted order.
Different API for the "look for a cached value other than this one"
gesture common for Spectre variants.
As a motivating example, I ported spectre_v1_pht_sa to use the new class
(in part because it runs tests in CI). I also added a new test in CI for
TimingArray that fails if it doesn't identify the cached value more than
85% of the time or if it ever identifies the wrong cached value.
TimingArray
is a new API and implementation for making it easy to induce and measure cache timing side-channels.Differences from
CacheSideChannel
:TimingArray
computes its own threshold for recognizing when a memory read came from cache, so callers don't need to induce their own "known cached" value. That means no moreAddHitAnd...
variant and less disruption caused by the "look for cached read" action.TimingArray
spreads elements across pages and cache lines, improving cache use and therefore side-channel signal.As a motivating example, I ported
spectre_v1_pht_sa
to use the new class (in part because it runs tests in CI). I also added a new test in CI forTimingArray
that fails if it doesn't identify the cached value more than 85% of the time or if it ever identifies the wrong cached value.