historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: speck@linutronix.de
Subject: Re: [PATCH 3/4] V8 more sampling fun 3
Date: Fri, 17 Apr 2020 21:22:10 +0200	[thread overview]
Message-ID: <87imhxzzml.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200417131947.hg3a6225lmislk77@treble>

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

  parent reply	other threads:[~2020-04-17 19:22 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-16  0:14 [MODERATED] [PATCH 0/4] V8 more sampling fun 0 mark gross
2020-01-16 22:16 ` [MODERATED] [PATCH 3/4] V8 more sampling fun 3 mark gross
2020-01-30 19:12 ` [MODERATED] [PATCH 4/4] V8 more sampling fun 4 mark gross
2020-03-17  0:56 ` [MODERATED] [PATCH 1/4] V8 more sampling fun 1 mark gross
2020-03-17  0:56 ` [MODERATED] [PATCH 2/4] V8 more sampling fun 2 mark gross
2020-04-16 17:15 ` [MODERATED] Re: [PATCH 1/4] V8 more sampling fun 1 Josh Poimboeuf
2020-04-16 17:30   ` Borislav Petkov
2020-04-16 17:16 ` [MODERATED] Re: [PATCH 2/4] V8 more sampling fun 2 Josh Poimboeuf
2020-04-16 17:33   ` [MODERATED] " Borislav Petkov
2020-04-16 22:47     ` mark gross
2020-04-16 17:17 ` [MODERATED] Re: [PATCH 3/4] V8 more sampling fun 3 Josh Poimboeuf
2020-04-16 17:44   ` Borislav Petkov
2020-04-16 18:01     ` Josh Poimboeuf
2020-04-16 22:45       ` mark gross
2020-04-16 22:57     ` mark gross
2020-04-17 12:34     ` Thomas Gleixner
2020-04-17 13:19       ` [MODERATED] " Josh Poimboeuf
2020-04-17 16:46         ` Luck, Tony
2020-04-17 19:22         ` Thomas Gleixner [this message]
2020-04-16 22:54   ` mark gross
2020-04-16 17:20 ` [MODERATED] Re: [PATCH 4/4] V8 more sampling fun 4 Josh Poimboeuf
2020-04-16 17:49   ` [MODERATED] " Borislav Petkov
2020-04-16 22:57     ` mark gross
2020-04-20 14:30     ` mark gross
2020-04-20 16:17       ` Thomas Gleixner
2020-04-20 22:30         ` [MODERATED] " mark gross
2020-04-20 21:45       ` Slow Randomizing Boosts Denial of Service - Bulletin #1 Thomas Gleixner
2020-04-23 21:35         ` [MODERATED] " mark gross
2020-04-24  7:01           ` Greg KH
2020-04-27 15:10             ` mark gross
2020-04-21 17:30 ` [MODERATED] Re: [PATCH 4/4] V8 more sampling fun 4 Borislav Petkov
2020-04-21 17:34   ` Andrew Cooper
2020-04-21 18:19     ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87imhxzzml.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=speck@linutronix.de \
    --subject='Re: [PATCH 3/4] V8 more sampling fun 3' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).