[MODERATED] Re: [PATCH v5 08/11] TAAv5 8

On Wed, Oct 16, 2019 at 07:05:33AM +0200, speck for Jiri Kosina wrote:
> But again, given Pawan's (surprising to me, I'd still like to find this 
> detail documented somewhere in Intel's materials) statement that there 
> will never be a situation when some older CPU with MDS_NO will see 
> ARCH_CAP_TSX_CTRL_MSR exposed by new ucode, I see this as much less 
> pressing issue, and we could get away with tsx=off, as the number 
> immediate regressions will be minimal.
> 

Here's a rough timeline.

"Old" CPUs = everything vulnerable to MDS before:
	Cascade Lake (model 0x55, stepping 0x6, 0x7),
	Whiskey Lake (model 0x8E, stepping 0xC),
	Coffee Lake refresh (model 0x9E, stepping 0xD)

   These don't set MDS_NO. They already have (since May 14) a microcode update to
   enable MD_CLEAR (VERW + enhanced L1D flush). They are vulnerable to TAA, but
   the existing MDS fixes also mitigate TAA. They are not going to get a
   u-code update for TAA. They will not have TSX_CTRL.


"Current" CPUs (Cascade Lake, Whiskey Lake, Coffee Lake refresh).
   Out of the box these have MDS_NO=1. They set the CPUID MD_CLEAR bit
   (even though VERW doesn't flush the store buffers, fill buffers & load ports.
   Blame the VMM folks for talking us into doing that).

   There is (Embargo: Nov 12) a microcode update for these CPUS that:
   1) Enables the VERW/L1D flush of fill buffers, store buffers, load ports
   2) Provides the TSX_CTRL MSR

   OS can choose whether to mitigate TAA by either turning off TSX, or by
   using VERW.  [Note that because MD_CLEAR isn't a useful indicator here
   OS can use the existence of TSX_CTRL to determine whether VERW is effective]

"Future" CPUs
   These will set TAA_NO in additon to MDS_NO.  Intel has said that we will
   continue to support TSX_CTRL.

-Tony