[MODERATED] Re: [PATCH 3/4] V8 more sampling fun 3

On Fri, Apr 17, 2020 at 02:34:41PM +0200, speck for Thomas Gleixner wrote:
> speck for Borislav Petkov <[email protected]> writes:
> > On Thu, Apr 16, 2020 at 12:17:23PM -0500, speck for Josh Poimboeuf wrote:
> >
> > While it is present on all affected CPU models, the microcode mitigation
> > is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the
> > cases where TSX is not supported or has been disabled with TSX_CTRL.
> 
> If the CPU has does not expose TSX_CTRL and has FEATURE_RTM disabled (BIOS
> or fused off) then we declare it as non vulnerable.
> 
> If the CPU exposes TSX_CTRL then we declare it vulnerable and decide in
> the mitigation selection whether it is vulnerable or not depending on
> the RTM state. If RTM is off, we say: "Mitigation: TSX disabled".
> 
> IMO the whole tsx_fused_off() logic is pointless. It does not matter
> whether TSX got fused off or disabled in BIOS or disabled via
> TSX_CTRL. The CPU model is affected but the problem is mitigated because
> TSX is disabled.

The idea is that if TSX is *permanently* off, there's no way to trigger
the bug, regardless of how the user has things configured in BIOS or the
kernel.  So from the user's standpoint, the CPU is not affected, and
never was, regardless of kernel/BIOS settings and microcode.

Is there not a way to distinguish "disabled in BIOS" from "permanently
fused off"?  If not, then yes we should just consider all of them
"Mitigation: TSX disabled".

> Aside of that the tsx_fused_off() logic depends on the non-availability
> of TSX_CTRL. TSX_CTRL is available even on CPUs which enumerate TAA_NO,
> but I don't see any check for TAA_NO or BUG_TAA anywhere.
> 
> Is SBRDS on MDS_NO parts independent of TAA, i.e. does it solely depend
> on the fact that RTM is on?

I had assumed there are no parts in the SRBDS blacklist with TAA_NO.

-- 
Josh