From: Andrew Cooper <andrew.cooper3@citrix.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 4/9] TAA 4
Date: Fri, 25 Oct 2019 10:12:04 +0100 [thread overview]
Message-ID: <daad5bb7-f4bd-4a02-4c85-a315b22c25e3@citrix.com> (raw)
In-Reply-To: <2ca83125-fed2-116a-41f9-608eeb7f5911@citrix.com>
[-- Attachment #1: Type: text/plain, Size: 3188 bytes --]
On 24/10/2019 21:48, speck for Andrew Cooper wrote:
> On 24/10/2019 20:49, speck for Josh Poimboeuf wrote:
>> 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.
>>
> I'll bring this up with the group. I bet we are not the only people
> wondering the same, and it won't do any downstream users any good if
> they see conflicting descriptions from software vendors.
Preliminary feedback suggests that some vendors are definitely going
with TAA being a disjoint set to MDS, and other vendors are leaning in
that direction.
We should wait a bit longer for more views and opinions, as I think my
question was fairly late US time anyway yesterday.
~Andrew
next prev parent reply other threads:[~2019-10-25 9:12 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
2019-10-24 20:48 ` Andrew Cooper
2019-10-25 9:12 ` Andrew Cooper [this message]
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=daad5bb7-f4bd-4a02-4c85-a315b22c25e3@citrix.com \
--to=andrew.cooper3@citrix.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).