Re: YASV (Yet Another Security Vulnearability)

On 7/30/24 9:45 PM, Paul A. Clayton wrote:
[snip]

One can also theoretically alter the sense of a prediction state
or the hysteresis by XORing with other data. XORing a hysteresis
bit with one bit derived from the branch address might have a
beneficial effect on interference. (Agree prediction can also
change the sense of a predictor bit. For the hysteresis bit, if
it is not used for a quick confidence estimate, the backward/
forward character of the static branch could be used to bias the
hysteresis. This might not actually be useful, but is an
obvious design possibility.) I do not know how much such would
affect retraining. Inverting the hysteresis bit sense for half
of the aliasing branches would seem to speed retraining when the
hysteresis is commonly "strongly" (half of aliases would be
interpreted as "weakly")

Another possibility would be to use a different indexing function
for the hysteresis bits. I was thinking that this might provide a
limited benefit similar to gskewed prediction as the hysteresis
would usually alias in different branches than the prediction.
However, this might increase the destructiveness of aliasing. A
strongly taken branch might have a destructive aliaser whose
hysteresis is "biased not taken", leading to a change of the
prediction. An agreeing hysteresis would not have this weakness
as much because most entries would be "strongly agree" not "weakly
agree", but that would also mean that hysteresis alias would not
be as important.
(The unproduced Alpha EV8 used an agree hysteresis and had half
as many global 0 table and Meta table hysteresis bits as
prediction bits. ["Design Tradeoffs for the Alpha EV8 Conditional
Branch Predictor", André Seznec et al., 2002])
An interesting possibility would be is _extra_ mispredictions
resulted in choosing a different entry (which applies with meta
predictors and other sophisticated predictors).
This brings to mind the possibility of having different ways in
a TAGE-like predictor use different hashing functions to generate
the tag. If a useless entry was available in a set, detection of
an alias could move the useful entry into the useless entry that
would be less likely to alias in the tag. Swapping entries would
allow alias reduction even when all ways in a set have useful
entries, but the extra information is missing for one entry.
Even victimization would require the way change to be for the
dominant branch (e.g., sufficient confidence reduction might
trigger the change when the prediction is correct, assuming that
the aliasing branch will generally mispredict). I suspect this
would be a useless complication, but is seems an interesting
possibility. (Rather than swapping, one might just use an extra
bit to indicate which hashing function was used for the tag.
destructive aliasing might then choose the alternative hashing
function. Determining the desired branch to use the entry seems
a significant problem.) (At least I find some enjoyment in
thinking about such, even if the result is useless and does not
inspire a useful thought from someone else.)