Re: Plumbers CF MCs

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 23/03/2021 19:53, Peter Zijlstra wrote:
> On Tue, Mar 23, 2021 at 07:29:01PM +0000, Andrew Cooper wrote:
>> For the compiler folk here, the tl;dr is that indirect CALL/JMP (i.e.
>> function pointers, jump tables) and RET instructions may speculatively
>> execute the next sequential instruction(s) before taking the control
>> flow change into account. 
> So JMP and RET can trivially have INT3 following in such a way that that
> instruction is never in the actual execution path. This is obviously not
> possible for CALL.
>
> For CALL we can follow with LFENCE (hurts), or if we can get a limit
> on how many instructions deep the speculation gap is, a bunch of NOPs.
> Or possibly nothing at all.
>
> As such it might make sense to have these two cases separated out.

Agreed.

There is architectural execution following an indirect CALL, so we will
only be speculating what we will execute non-speculatively later.  I
can't see any situation where this would be speculatively dangerous.

For indirect JMP, whether you care about stopping speculation depends on
how likely it is that you'll enter case 0 of a switch statement.  That
said, for profile optimised code, the chances are that the hotpath(s)
are in an if/else chain, so I don't think it is worth attempting to do
anything interesting here.

Both the Intel and AMD documents on the matter say to use LFENCE, but
that is a simplified set of instruction to cover all 3 cases.  Given
that we probably want to split CALL away from JMP/RET, then INT3 is the
shortest speculation block at a single byte, and thus has least .text
size impact.

~Andrew