RE: [patch 00/38] x86/retbleed: Call depth tracking mitigation

[David Laight <David.Laight@ACULAB.COM>]

From: Linus Torvalds
> Sent: 19 July 2022 01:02
> 
> On Mon, Jul 18, 2022 at 4:52 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Honestly, I think that would be a better model - yes, you lose 8 bits
> > of hash, but considering that apparently the current KCFI code
> > *guarantees* that the hash pattern will exist even outside the actual
> > target pattern,
> 
> Gaah, I'm being stupid,. You still get the value collision, since the
> int3 byte pattern would just be part of the compare pattern.
> 
> You'd have to use some multi-instruction compare to avoid having the
> pattern in the instruction stream. Probably with another register.
> Like
> 
>         movl -FIXED_OFFSET(%eax),%rdx
>         addl $ANTI_PATTERN,%rdx
>         je ok
> 
> so that the "compare" wouldn't use the same pattern value, but be an
> add with the negated pattern value instead.
> 
> The extra instruction is likely less of a problem than the extra register used.

Shouldn't it be testing the value the caller supplied?

The extra instruction is likely to be one clock - I doubt it will
sensibly run in parallel with code later in the function.

The larger costs are (probably) polluting the D$ with I addresses
(already done by the caller) and the likely mispredicted 'je ok'.
Unless the function has been recently called the 'je ok' gets
static prediction.
While traditionally that would predict a forwards branch 'not taken'
ISTR more recent Intel cpu just use the predictor output - ie random.
Not at all sure about AMD cpu though.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)