historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 3/4] V8 more sampling fun 3
Date: Fri, 17 Apr 2020 08:19:47 -0500	[thread overview]
Message-ID: <20200417131947.hg3a6225lmislk77@treble> (raw)
In-Reply-To: <874ktimgta.fsf@nanos.tec.linutronix.de>

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".

> 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

  reply	other threads:[~2020-04-17 13:19 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       ` Josh Poimboeuf [this message]
2020-04-17 16:46         ` [MODERATED] " Luck, Tony
2020-04-17 19:22         ` Thomas Gleixner
2020-04-16 22:54   ` [MODERATED] " 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=20200417131947.hg3a6225lmislk77@treble \
    --to=jpoimboe@redhat.com \
    --cc=speck@linutronix.de \
    --subject='[MODERATED] 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).