From: Josh Poimboeuf <jpoimboe@redhat.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 4/9] TAA 4
Date: Thu, 24 Oct 2019 14:49:43 -0500 [thread overview]
Message-ID: <20191024194943.rh2qzpnq2uzh3ulo@treble> (raw)
In-Reply-To: <d3b3c34b-b0e6-bb03-0b2d-ca2aaea18d5d@citrix.com>
On Thu, Oct 24, 2019 at 08:13:44PM +0100, speck for Andrew Cooper wrote:
> On 24/10/2019 19:56, speck for Josh Poimboeuf wrote:
> > On Thu, Oct 24, 2019 at 07:23:57PM +0100, speck for Andrew Cooper wrote:
> >> On 24/10/2019 17:43, speck for Borislav Petkov wrote:
> >>> On Thu, Oct 24, 2019 at 10:32:40AM -0500, speck for Josh Poimboeuf wrote:
> >>>> As I said before this would be a lot nicer if we could just add NO_TAA
> >>>> to the cpu_vuln_whitelist.
> >>> We're waiting for a list of CPUs from Intel here, right?
> >>>
> >> There is no model list required. Vulnerability to TAA is calculable
> >> directly from existing architectural sources.
> > Can you elaborate? Earlier I suggested relying on NO_MDS in
> > cpu_vuln_whitelist, but I believe you said that's not sufficient,
> > because some of the non-MDS models don't have TSX, in which case we
> > shouldn't set TAA_BUG.
> >
> > Which models are those?
>
> Ok. First things first. Do you (and by this, I really mean Linux) want
> to consider TAA an overlapping set with MDS, or a disjoint set?
>
> After considering this for ages, and particularly, how to explain it
> clearly to non-experts in Xen's security advisory, I chose to go with this:
>
> ---8<---
> Vulnerability to TAA is a little complicated to quantify.
>
> In the pipeline, it is just another way to get speculative access to
> stale load port, store buffer or fill buffer data, and therefore can be
> considered a superset of MDS. On parts which predate MDS_NO, the
> existing VERW flushing will mitigate this sidechannel as well.
>
> On parts which contain MDS_NO, the lack of VERW flushing means that an
> attacker can still target microarchitectural buffers to leak secrets.
> Therefore, we consider TAA to be the set of parts which have MDS_NO but
> lack TAA_NO.
> ---8<---
>
> The simplifying fact is that vulnerability to TAA doesn't matter on CPUs
> which don't advertise MDS_NO, because you're already doing VERW and
> disabling hyperthreading, *and* can't turn TSX off if it actually available.
>
> People who were not taking MDS mitigations in the first place won't
> change their minds because of TAA, either.
Good question.
The current Linux patches consider them overlapping. But it _might_
possibly be easier to communicate if we considered them disjoint. I
don't know if there's a good answer, but at this point it might be
easiest to stick with our current overlapping approach.
--
Josh
next prev parent reply other threads:[~2019-10-24 19:49 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 8:20 [MODERATED] [PATCH 0/9] TAA 0 Borislav Petkov
2019-10-23 8:45 ` [MODERATED] [PATCH 1/9] TAA 1 Pawan Gupta
2019-10-24 15:22 ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:23 ` Borislav Petkov
2019-10-24 16:42 ` Josh Poimboeuf
2019-10-23 8:52 ` [MODERATED] [PATCH 2/9] TAA 2 Pawan Gupta
2019-10-23 9:01 ` [MODERATED] [PATCH 3/9] TAA 3 Pawan Gupta
2019-10-24 15:30 ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:33 ` Borislav Petkov
2019-10-24 16:43 ` Josh Poimboeuf
2019-10-24 17:39 ` Andrew Cooper
2019-10-24 19:45 ` Borislav Petkov
2019-10-24 19:59 ` Josh Poimboeuf
2019-10-24 20:05 ` Borislav Petkov
2019-10-24 20:14 ` Josh Poimboeuf
2019-10-24 20:36 ` Borislav Petkov
2019-10-24 20:43 ` Andrew Cooper
2019-10-24 20:55 ` Borislav Petkov
2019-10-24 20:44 ` Josh Poimboeuf
2019-10-24 20:07 ` Andrew Cooper
2019-10-24 20:17 ` Borislav Petkov
2019-10-24 22:38 ` Andrew Cooper
2019-10-25 6:03 ` Pawan Gupta
2019-10-25 7:25 ` Borislav Petkov
2019-10-25 7:17 ` Borislav Petkov
2019-10-25 9:08 ` Andrew Cooper
2019-10-27 7:48 ` Borislav Petkov
2019-10-27 7:49 ` [MODERATED] [AUTOREPLY] [MODERATED] [AUTOREPLY] Automatic reply: " James, Hengameh M
2019-10-24 19:47 ` [MODERATED] " Pawan Gupta
2019-10-30 13:28 ` Greg KH
2019-10-30 14:48 ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-30 17:24 ` [MODERATED] " Pawan Gupta
2019-10-30 19:27 ` Greg KH
2019-10-30 19:44 ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-11-01 9:35 ` Greg KH
2019-11-01 13:15 ` [MODERATED] " Borislav Petkov
2019-11-01 14:33 ` Greg KH
2019-11-01 18:42 ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-23 9:30 ` [MODERATED] [PATCH 4/9] TAA 4 Pawan Gupta
2019-10-24 15:32 ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:43 ` Borislav Petkov
2019-10-24 17:15 ` Josh Poimboeuf
2019-10-24 17:23 ` Pawan Gupta
2019-10-24 17:27 ` Pawan Gupta
2019-10-24 17:34 ` Josh Poimboeuf
2019-10-24 18:23 ` Andrew Cooper
2019-10-24 18:56 ` Josh Poimboeuf
2019-10-24 18:59 ` Josh Poimboeuf
2019-10-24 19:13 ` Andrew Cooper
2019-10-24 19:49 ` Josh Poimboeuf [this message]
2019-10-24 20:48 ` Andrew Cooper
2019-10-25 9:12 ` Andrew Cooper
2019-10-25 0:49 ` Pawan Gupta
2019-10-25 7:36 ` Borislav Petkov
2019-10-23 10:19 ` [MODERATED] [PATCH 5/9] TAA 5 Pawan Gupta
2019-10-24 18:30 ` [MODERATED] " Greg KH
2019-10-23 10:23 ` [MODERATED] [PATCH 6/9] TAA 6 Pawan Gupta
2019-10-23 10:28 ` [MODERATED] [PATCH 7/9] TAA 7 Pawan Gupta
2019-10-24 15:35 ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:42 ` Borislav Petkov
2019-10-24 18:20 ` Jiri Kosina
2019-10-24 19:53 ` Borislav Petkov
2019-10-24 20:02 ` Josh Poimboeuf
2019-10-24 20:08 ` Borislav Petkov
2019-10-23 10:32 ` [MODERATED] [PATCH 8/9] TAA 8 Pawan Gupta
2019-10-24 16:03 ` [MODERATED] " Josh Poimboeuf
2019-10-24 17:35 ` Borislav Petkov
2019-10-24 18:11 ` Josh Poimboeuf
2019-10-24 18:55 ` Pawan Gupta
2019-10-25 8:04 ` Borislav Petkov
2019-10-23 10:35 ` [MODERATED] [PATCH 9/9] TAA 9 Michal Hocko
2019-10-24 16:10 ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:58 ` Borislav Petkov
2019-10-25 10:47 ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-25 13:05 ` [MODERATED] " 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=20191024194943.rh2qzpnq2uzh3ulo@treble \
--to=jpoimboe@redhat.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 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).