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.

~Andrew