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

[Thomas Gleixner <tglx@linutronix.de>]

speck for Josh Poimboeuf <speck@linutronix.de> writes:
> On Fri, Apr 17, 2020 at 02:34:41PM +0200, speck for Thomas Gleixner wrote:
>> speck for Borislav Petkov <speck@linutronix.de> 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".

I don't have access to a MDS_NO part with a BIOS switch for TSX, so I
can't investigate it.

Thanks,

        tglx