From: Andy Lutomirski <email@example.com> To: X86 ML <firstname.lastname@example.org>, LKML <email@example.com>, David Kaplan <David.Kaplan@amd.com>, Andrew Cooper <firstname.lastname@example.org>, David Woodhouse <email@example.com>, Josh Poimboeuf <firstname.lastname@example.org>, Kees Cook <email@example.com>, Jann Horn <firstname.lastname@example.org> Subject: Do we need to do anything about "dead µops?" Date: Sat, 1 May 2021 09:26:33 -0700 [thread overview] Message-ID: <CALCETrXRvhqw0fibE6qom3sDJ+nOa_aEJQeuAjPofh=8h1Cujg@mail.gmail.com> (raw) 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
next reply other threads:[~2021-05-01 16:26 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-01 16:26 Andy Lutomirski [this message] 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
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CALCETrXRvhqw0fibE6qom3sDJ+nOa_aEJQeuAjPofh=8h1Cujg@mail.gmail.com' \ --email@example.com \ --cc=David.Kaplan@amd.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Do we need to do anything about "dead µops?"' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).