All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: speck@linutronix.de
Subject: [MODERATED] Re: LVI
Date: Tue, 26 Nov 2019 11:37:22 +0100	[thread overview]
Message-ID: <20191126103722.GC1418669@kroah.com> (raw)
In-Reply-To: <20191126005417.GG84886@tassilo.jf.intel.com>

On Mon, Nov 25, 2019 at 04:54:17PM -0800, speck for Andi Kleen wrote:
> 
> Hi Folks,
> 
> We (well Tony, but he's currently on vacation) did a lot of analysis on LVI and we
> concluded the kernel does not need any new changes. That's why you didn't see any
> patches from Intel on this.
> 
> Longer story: 
> 
> Assists are somewhat messy and can happen in many circumstances. However most
> are rare and hard to trigger, so if you get them they're typically not usable
> for a high loop count practical side channel. The main exception is the page A/D
> assist which can be triggered in the kernel by *_user()
> 
> *_user is protected by STAC/CLAC already and those have strong enough semantics
> to stop an LVI attack outside the uaccess region. But of course there are CPUs
> (pre BDW) which don't have STAC/CLAC.
> 
> But to do anything with LVI you need a Spectre v1 style read gadget. Without 
> a gadget the attack is not feasible. And those gadgets are usually Spectre v1
> problems, so they would need to be fixed anyways.
> 
> We already spent a lot of time looking for those in the past and fixing the few
> found. Tony did an additional full tree audit, and the only additional case
> found was in Infiniband. The patch for this is already upstream for some time
> ("61f259821dd3306e49: IB/core: Add mitigation for Spectre V1")

What's to keep these types of things coming back into our tree?  Do we
have anything that can scan for them yet?

> So in summary, on modern CPUs (BDW+) STAC/CLAC mitigates LVIs, and on older CPUs the
> Spectre V1 mitigation.

So, all is good and the researchers can release their paper now and get
on with their lives?  Or is there something that we still need to do
here?

Do you have the PoC to share with us so that we can verify all of this?

> The only real active (and messy) mitigation for LVI needed is when you're creating
> SGX enclaves, but I assume noone here is interested in that.

We don't care, no, but do our users?  I think some of them used to,
before it was found to not be useful at all :)

thanks,

greg k-h

  reply	other threads:[~2019-11-26 10:37 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-19 17:40 [MODERATED] LVI Josh Poimboeuf
2019-11-19 17:51 ` [MODERATED] LVI Andrew Cooper
2019-11-19 18:27   ` Josh Poimboeuf
2019-11-19 19:26     ` Andrew Cooper
2019-11-20  9:52     ` Paolo Bonzini
2019-11-19 18:12 ` Greg KH
2019-11-19 18:21   ` Josh Poimboeuf
2019-11-19 18:46     ` Greg KH
2019-11-19 18:21   ` Paolo Bonzini
2019-11-19 18:22 ` Andrew Cooper
2019-11-19 18:27   ` Josh Poimboeuf
2019-11-19 18:36     ` Luck, Tony
2019-11-20 17:02       ` Greg KH
2019-11-19 18:39     ` Andrew Cooper
2019-11-19 21:00       ` Josh Poimboeuf
2019-11-19 21:03         ` Josh Poimboeuf
2019-11-20 14:11           ` Andrew Cooper
2019-11-20  8:04 ` Peter Zijlstra
2019-11-20  9:49   ` Andrew Cooper
2019-11-20 17:13 ` Josh Poimboeuf
2019-11-20 17:25   ` Greg KH
2019-11-20 17:29     ` Tyler Hicks
2019-11-20 17:30     ` Andrew Cooper
2019-11-20 17:46       ` Greg KH
2019-11-20 19:09     ` Peter Zijlstra
2019-11-20 19:19       ` Greg KH
2019-11-21  0:50         ` LVI Thomas Gleixner
2019-11-21 13:45           ` [MODERATED] LVI Greg KH
2019-11-26  0:54 ` Andi Kleen
2019-11-26 10:37   ` Greg KH [this message]
2019-11-26 18:23     ` Andi Kleen
2019-11-27  7:38       ` Greg KH
2019-11-26 10:55   ` Paolo Bonzini
2019-11-26 18:28     ` Andi Kleen

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=20191126103722.GC1418669@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=speck@linutronix.de \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.