Re: Plumbers CF MCs

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Mar 23, 2021 at 08:36:12PM -0400, Steven Rostedt wrote:
> On Tue, 23 Mar 2021 23:12:46 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Tue, Mar 23, 2021 at 08:53:58PM +0100, Peter Zijlstra wrote:
> > 
> > > Another utterly disguisting option is to align all CALL instructions on
> > > 8 bytes and have it followed by 3 INT3s to make it 8 bytes long. Then
> > > have every function prologue round up the return address. This should
> > > work with tail-call optimizations because the round-up is NOP when
> > > repeated. The obvious down-side is that it will utterly wreck the RSB  
> > 
> > Slightly less horrible: "CALL func; INT3" + "INC (%RSP); RET; INT3".
> > It still completely wrecks RSB, but isn't nearly as wasteful.
> 
> I'm confused. Why is speculation after a CALL dangerous? That code will
> be executed on the return of the call anyway. That is, it's not
> speculating something that wont execute in the future, whereas code
> after RET and JMP wont be executed.

Like I just wrote to Andrew; it mostly isn't going to be. But there will
be cases where running the code after, with the register contents from
before, will get you a nice speculation gadget.

The big problem is, like with Spectre-v1 compiler mitigations,
recognising when it is and isn't a problem. Mostly compilers tend to
take the safe option (understandably) and we end up with an incredible
amount of LFENCE instructions and performance will suck.

For SLS at least the CALL+LFENCE pattern is trivial enough to recognise
and we can patch it out at runtime, with the only side effect being
code bloat and I$ fail. That same isn't true for Spectre-v1 mitigations,
where LFENCEs are emitted at less obviously recognised places.