All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH v3 00/32] MDSv3 12
Date: Wed, 9 Jan 2019 10:14:55 -0800	[thread overview]
Message-ID: <20190109181455.GU6118@tassilo.jf.intel.com> (raw)
In-Reply-To: <CAHk-=wh6hmASEo8qmc+DE82JWUovc7m19UNeObGdoK1NAKJiug@mail.gmail.com>

On Wed, Jan 09, 2019 at 09:35:22AM -0800, speck for Linus Torvalds wrote:
> On Wed, Jan 9, 2019 at 3:01 AM speck for Andi Kleen <speck@linutronix.de> wrote:
> >
> > VERW is not done unconditionally because it doesn't allow reporting
> > the correct status in the vulnerabilities file, which I consider important.
> > Instead we now have a mds=verw option that can be set as needed,
> > but is reported explicitely in the mitigation status.
> 
> I also don't see what the logic of this is AT ALL.
> 
> "Reporting" has absolutely nothign to do with "use VERW". The fact
> that you link the two is crazy.
> 
> The rule for VERW should be simple: use VERW if the CPU doesn't have
> the NOMDS bit set (or whatever the name is today).

The case that worried me is that with this we would end up
with some systems which are actually protected, but report vulnerable.

So you could not simply say

"If the sysfs file says you're vulnerable you're vulnerable"

but would need

"If the sysfs file says you're vulnerable, you're vulnerable except
<add some long paragraph of small print enumerating different
vmware and other hyper visor versions>"

Doesn't seem like a clear message for me.

With the current scheme at least only the people who see vulnerable
have to read the documentation and figure out the VMWare mess.

-Andi

  reply	other threads:[~2019-01-09 18:20 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-21  0:27 [MODERATED] [PATCH v3 00/32] MDSv3 12 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 01/32] MDSv3 7 Andi Kleen
2019-01-09 17:38   ` [MODERATED] " Konrad Rzeszutek Wilk
2018-12-21  0:27 ` [MODERATED] [PATCH v3 02/32] MDSv3 22 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 03/32] MDSv3 5 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 04/32] MDSv3 3 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 05/32] MDSv3 0 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 06/32] MDSv3 8 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 07/32] MDSv3 21 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 08/32] MDSv3 15 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 09/32] MDSv3 10 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 10/32] MDSv3 11 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 11/32] MDSv3 29 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 12/32] MDSv3 19 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 13/32] MDSv3 6 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 14/32] MDSv3 28 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 15/32] MDSv3 27 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 16/32] MDSv3 4 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 17/32] MDSv3 13 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 18/32] MDSv3 32 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 19/32] MDSv3 16 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 20/32] MDSv3 24 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 21/32] MDSv3 25 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 22/32] MDSv3 23 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 23/32] MDSv3 31 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 24/32] MDSv3 30 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 25/32] MDSv3 9 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 26/32] MDSv3 14 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 27/32] MDSv3 18 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 28/32] MDSv3 20 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 29/32] MDSv3 26 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 30/32] MDSv3 17 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 31/32] MDSv3 1 Andi Kleen
2018-12-21  0:27 ` [MODERATED] [PATCH v3 32/32] MDSv3 2 Andi Kleen
2019-01-09 17:09 ` [MODERATED] Re: [PATCH v3 00/32] MDSv3 12 Linus Torvalds
2019-01-09 17:31   ` Andi Kleen
2019-01-09 17:38     ` Linus Torvalds
2019-01-09 18:06       ` Andi Kleen
2019-01-09 18:14         ` Linus Torvalds
2019-01-09 19:49           ` Andi Kleen
2019-01-09 17:18 ` Konrad Rzeszutek Wilk
2019-01-09 17:41   ` Andi Kleen
2019-01-09 18:09     ` Konrad Rzeszutek Wilk
2019-01-09 18:42       ` Andi Kleen
2019-01-09 17:35 ` Linus Torvalds
2019-01-09 18:14   ` Andi Kleen [this message]
2019-01-09 18:32     ` Linus Torvalds
2019-01-10  6:01     ` Jiri Kosina
2019-01-10 16:05       ` Andi Kleen
2019-01-09 17:39 ` 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=20190109181455.GU6118@tassilo.jf.intel.com \
    --to=ak@linux.intel.com \
    --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.