From: Josh Poimboeuf <jpoimboe@redhat.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 3/4] V7 more sampling fun 3
Date: Tue, 14 Apr 2020 16:23:27 -0500 [thread overview]
Message-ID: <20200414212327.eyo4xdldwuhnqzzz@treble> (raw)
In-Reply-To: <20200414210302.GC29751@mtg-dev.jf.intel.com>
On Tue, Apr 14, 2020 at 02:03:02PM -0700, speck for mark gross wrote:
> > > + [SRBDS_MITIGATION_NOT_AFFECTED_TSX_OFF] = "Not affected (TSX disabled)",
> >
> > The CPU *is* affected, it just happens to be mitigated, right?
> This depends on perspective.
> The only mitigation to SRBS is for the uCode to serialize access to the off
> core hwRNG and to do a ghost transfer of a through away random number such that
> if it leaks you don't get the right random number. I think there may be some
> buffer clearing in there too.
>
> Disabling TSX from that point of view is not mitigating the issue so much as
> hiding exposure to it.
>
> I can see it either way. Not sure which is better. After reading my logic do
> you still think it would make more sence to change "Not affected (TSX
> disabled)" to "Mitigated: TSX disabled"?
From a user's perspective, "hiding exposure" is the same as a
mitigation. So I think it makes sense to call it a mitigation.
> > > + */
> > > + if ((ia32_cap & ARCH_CAP_MDS_NO) &&
> > > + !((ia32_cap & ARCH_CAP_TSX_CTRL_MSR) ||
> > > + cpu_has(c, X86_FEATURE_RTM)))
> > > + goto srbds_not_affected;
> > > +
> > > + setup_force_cpu_bug(X86_BUG_SRBDS);
> > > + }
> > > +srbds_not_affected:
> > > +
> > > if (cpu_matches(NO_MELTDOWN, cpu_vuln_whitelist))
> > > return;
> >
> > I'm thinking it would be more readable to have the newline between the
> > bracket and the 'if', instead of between the label and the 'if'.
> so, lose the newline between the label and the if?
Yes, and add one between the '}' and the label.
--
Josh
next prev parent reply other threads:[~2020-04-14 21:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-13 18:10 [MODERATED] [PATCH 0/4] V7 more sampling fun 0 mark gross
2020-01-16 22:16 ` [MODERATED] [PATCH 3/4] V7 more sampling fun 3 mark gross
2020-01-30 19:12 ` [MODERATED] [PATCH 4/4] V7 more sampling fun 4 mark gross
2020-03-17 0:56 ` [MODERATED] [PATCH 2/4] V7 more sampling fun 2 mark gross
2020-03-17 0:56 ` [MODERATED] [PATCH 1/4] V7 more sampling fun 1 mark gross
2020-04-14 3:48 ` [MODERATED] Re: [PATCH 3/4] V7 more sampling fun 3 mark gross
2020-04-14 16:23 ` Thomas Gleixner
2020-04-14 20:03 ` [MODERATED] " mark gross
2020-04-14 10:58 ` Thomas Gleixner
2020-04-14 16:43 ` [MODERATED] " mark gross
2020-04-14 20:02 ` Josh Poimboeuf
2020-04-14 21:03 ` mark gross
2020-04-14 21:23 ` Josh Poimboeuf [this message]
2020-04-14 21:53 ` mark gross
2020-04-14 20:05 ` Josh Poimboeuf
2020-04-14 21:59 ` mark gross
2020-04-14 22:46 ` Josh Poimboeuf
2020-04-15 20:59 ` mark gross
2020-04-15 12:58 ` Thomas Gleixner
2020-04-15 22:21 ` [MODERATED] " mark gross
2020-04-15 17:51 ` [MODERATED] Re: [PATCH 1/4] V7 more sampling fun 1 Borislav Petkov
2020-04-15 23:58 ` mark gross
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=20200414212327.eyo4xdldwuhnqzzz@treble \
--to=jpoimboe@redhat.com \
--cc=speck@linutronix.de \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).