linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Do we need to do anything about "dead µops?"
@ 2021-05-01 16:26 Andy Lutomirski
  2021-05-01 17:35 ` Andrew Cooper
  2021-05-03 23:30 ` Josh Poimboeuf
  0 siblings, 2 replies; 7+ messages in thread
From: Andy Lutomirski @ 2021-05-01 16:26 UTC (permalink / raw)
  To: X86 ML, LKML, David Kaplan, Andrew Cooper, David Woodhouse,
	Josh Poimboeuf, Kees Cook, Jann Horn

Hi all-

The "I See Dead µops" paper that is all over the Internet right now is
interesting, and I think we should discuss the extent to which we
should do anything about it.  I think there are two separate issues:

First, should we (try to) flush the µop cache across privilege
boundaries?  I suspect we could find ways to do this, but I don't
really see the point.  A sufficiently capable attacker (i.e. one who
can execute their own code in the dangerous speculative window or one
who can find a capable enough string of gadgets) can put secrets into
the TLB, various cache levels, etc.  The µop cache is a nice piece of
analysis, but I don't think it's qualitatively different from anything
else that we don't flush.  Am I wrong?

Second, the authors claim that their attack works across LFENCE.  I
think that this is what's happening:

load secret into %rax
lfence
call/jmp *%rax

As I understand it, on CPUs from all major vendors, the call/jmp will
gladly fetch before lfence retires, but the address from which it
fetches will come from the branch predictors, not from the
speculatively computed value in %rax.  So this is nothing new.  If the
kernel leaks a secret into the branch predictors, we have already
mostly lost, although we have a degree of protection from the various
flushes we do.  In other words, if we do:

load secret into %rax
<-- non-speculative control flow actually gets here
lfence
call/jmp *%rax

then we will train our secret into the predictors but also leak it
into icache, TLB, etc, and we already lose.  We shouldn't be doing
this in a way that matters.  But, if we do:

mispredicted branch
load secret into %rax
<-- this won't retire because the branch was mispredicted
lfence
<-- here we're fetching but not dispatching
call/jmp *%rax

then the leak does not actually occur unless we already did the
problematic scenario above.

So my tentative analysis is that no action on Linux's part is required.

What do you all think?

--Andy

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-05-04 13:24 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-01 16:26 Do we need to do anything about "dead µops?" Andy Lutomirski
2021-05-01 17:35 ` Andrew Cooper
2021-05-03 23:30 ` Josh Poimboeuf
2021-05-04  1:31   ` Andy Lutomirski
2021-05-04  3:16     ` Josh Poimboeuf
2021-05-04 13:06       ` David Laight
2021-05-04 13:24         ` Josh Poimboeuf

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox