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