From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH v7 04/10] TAAv7 4
Date: Tue, 22 Oct 2019 17:27:56 -0700 [thread overview]
Message-ID: <20191023002756.GB30440@guptapadev.amr> (raw)
In-Reply-To: <20191022220555.GZ31458@zn.tnic>
On Wed, Oct 23, 2019 at 12:05:55AM +0200, speck for Borislav Petkov wrote:
> On Tue, Oct 22, 2019 at 11:53:21PM +0200, Borislav Petkov wrote:
> > On Tue, Oct 22, 2019 at 02:29:02PM -0700, speck for Pawan Gupta wrote:
> > > Side effect of RTM check ahead of X86_BUG_TAA will be a dmesg print
> > > "Mitigation: TSX disabled" when X86_BUG_TAA is not set.
> >
> > So what you're trying to tell me is that you don't want to print that
> > message at all?
> >
> > if (!boot_cpu_has(X86_FEATURE_RTM)) {
> > taa_mitigation = TAA_MITIGATION_TSX_DISABLE;
> > return;
> > }
> >
> > How's that?
>
> And to perhaps answer your other question from below maybe - I'm
> assuming you want something like this:
>
> if (!boot_cpu_has(X86_FEATURE_RTM)) {
> taa_mitigation = TAA_MITIGATION_TSX_DISABLE;
> setup_clear_cpu_bug(X86_BUG_TAA);
> return;
> }
>
> This is assuming X86_FEATURE_RTM really mirrors the CPUID bit. And that
> should be the case since if you do tsx_disable(), it will clear the
> CPUID bit through the MSR. IOW, when TSX is disabled, you're basically
> not affected by TAA, of course.
Sysfs mitigations are shown by a common function cpu_show_common() which
checks the X86_BUG_TAA bit. If we clear X86_BUG_TAA, cpu_show_common()
will show "Not affected" in sysfs. This would be when X86_BUG_TAA exists
in the hardware, but was mitigated by disabling TSX. In my opinion
correct output in this case should be "Mitigation: TSX disabled", which
is what it shows now.
I am sorry, I am failing to understand what problem are you trying to
solve by changing the order of X86_FEATURE_RTM and X86_BUG_TAA checks?
>
> > > > Also, from all the possible settings:
> > > >
> > > > [TAA_MITIGATION_OFF] = "Vulnerable",
> > > > [TAA_MITIGATION_UCODE_NEEDED] = "Vulnerable: Clear CPU buffers attempted, no microcode",
> > > > [TAA_MITIGATION_VERW] = "Mitigation: Clear CPU buffers",
> > > > [TAA_MITIGATION_TSX_DISABLE] = "Mitigation: TSX disabled",
> > > >
> > > > TAA_MITIGATION_TSX_DISABLE is the one that fits best for the !RTM case,
> > > > no?
> > >
> > > When X86_BUG_TAA is not set sysfs shows "Not affected" irrespective of
> > > value of taa_mitigation.
> > >
> > > cpu_show_common()
> > > {
> > > if (!boot_cpu_has_bug(bug))
> > > return sprintf(buf, "Not affected\n");
> > > [...]
> >
> > Sorry, I can't follow what you're trying to tell me here.
That when X86_BUG_TAA is not set, no matter what the value
taa_mitigation has, sysfs is always going to say "Not affected". So
the first check taa_select_mitigation() does is whether X86_BUG_TAA is
set. If no, do nothing and return. If yes set the appropriate
taa_mitigation.
When the user reads the sysfs file for vulnerabilities,
cpu_show_common() checks if the bug is present, if yes display the
mitigation string as per taa_mitigation, if no simply say "Not affected".
Thanks,
Pawan
next prev parent reply other threads:[~2019-10-23 0:34 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-21 20:22 [MODERATED] [PATCH v7 00/10] TAAv7 0 Pawan Gupta
2019-10-21 20:23 ` [MODERATED] [PATCH v7 01/10] TAAv7 1 Pawan Gupta
2019-10-21 20:24 ` [MODERATED] [PATCH v7 02/10] TAAv7 2 Pawan Gupta
2019-10-21 20:25 ` [MODERATED] [PATCH v7 03/10] TAAv7 3 Pawan Gupta
2019-10-21 20:26 ` [MODERATED] [PATCH v7 04/10] TAAv7 4 Pawan Gupta
2019-10-21 20:27 ` [MODERATED] [PATCH v7 05/10] TAAv7 5 Pawan Gupta
2019-10-21 20:28 ` [MODERATED] [PATCH v7 06/10] TAAv7 6 Pawan Gupta
2019-10-21 20:29 ` [MODERATED] [PATCH v7 07/10] TAAv7 7 Pawan Gupta
2019-10-21 20:30 ` [MODERATED] [PATCH v7 08/10] TAAv7 8 Pawan Gupta
2019-10-21 20:31 ` [MODERATED] [PATCH v7 09/10] TAAv7 9 Michal Hocko
2019-10-21 20:32 ` [MODERATED] [PATCH v7 10/10] TAAv7 10 Pawan Gupta
2019-10-21 21:32 ` [MODERATED] Re: [PATCH v7 00/10] TAAv7 0 Andy Lutomirski
2019-10-21 23:06 ` Andrew Cooper
2019-10-22 0:34 ` Pawan Gupta
2019-10-22 4:10 ` [MODERATED] Jon Masters
2019-10-22 5:53 ` [MODERATED] Pawan Gupta
2019-10-22 7:58 ` [MODERATED] Re: ***UNCHECKED*** [PATCH v7 07/10] TAAv7 7 Michal Hocko
2019-10-22 16:55 ` [MODERATED] " Pawan Gupta
2019-10-22 8:00 ` [MODERATED] Re: ***UNCHECKED*** [PATCH v7 09/10] TAAv7 9 Michal Hocko
2019-10-22 8:15 ` [MODERATED] Re: ***UNCHECKED*** [PATCH v7 03/10] TAAv7 3 Michal Hocko
2019-10-22 14:42 ` Josh Poimboeuf
2019-10-22 16:48 ` [MODERATED] " Pawan Gupta
2019-10-22 17:01 ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-22 17:35 ` Josh Poimboeuf
2019-10-22 14:38 ` [MODERATED] " Borislav Petkov
2019-10-22 16:58 ` Pawan Gupta
2019-10-22 14:48 ` Borislav Petkov
2019-10-22 17:00 ` Pawan Gupta
2019-10-22 17:16 ` [MODERATED] " Borislav Petkov
2019-10-22 18:07 ` [MODERATED] " Pawan Gupta
2019-10-22 15:07 ` Borislav Petkov
2019-10-22 18:36 ` Pawan Gupta
2019-10-22 18:59 ` [MODERATED] " Borislav Petkov
2019-10-22 16:51 ` [MODERATED] Re: [PATCH v7 04/10] TAAv7 4 Borislav Petkov
2019-10-22 17:02 ` Borislav Petkov
2019-10-22 18:00 ` Pawan Gupta
2019-10-22 18:12 ` [MODERATED] " Borislav Petkov
2019-10-22 19:16 ` Luck, Tony
2019-10-22 19:28 ` [MODERATED] " Borislav Petkov
2019-10-22 20:02 ` Luck, Tony
2019-10-22 20:48 ` [MODERATED] Jon Masters
2019-10-22 20:54 ` [MODERATED] Re: [PATCH v7 04/10] TAAv7 4 Borislav Petkov
2019-10-22 21:38 ` Josh Poimboeuf
2019-10-22 21:46 ` Borislav Petkov
2019-10-22 22:06 ` Josh Poimboeuf
2019-10-22 22:13 ` Borislav Petkov
2019-10-22 17:44 ` Pawan Gupta
2019-10-22 19:04 ` [MODERATED] " Borislav Petkov
2019-10-22 21:29 ` [MODERATED] " Pawan Gupta
2019-10-22 21:53 ` Borislav Petkov
2019-10-22 22:05 ` Borislav Petkov
2019-10-23 0:27 ` Pawan Gupta [this message]
2019-10-23 5:25 ` Pawan Gupta
2019-10-23 6:46 ` Borislav Petkov
2019-10-23 13:28 ` Pawan Gupta
2019-10-23 14:39 ` Borislav Petkov
2019-10-23 1:33 ` Pawan Gupta
2019-10-23 6:48 ` Borislav Petkov
2019-10-22 17:25 ` [MODERATED] Re: [PATCH v7 01/10] TAAv7 1 Josh Poimboeuf
2019-10-23 9:26 ` Borislav Petkov
2019-10-22 17:26 ` Josh Poimboeuf
2019-10-22 20:44 ` [MODERATED] Jon Masters
2019-10-22 17:47 ` [MODERATED] Re: [PATCH v7 03/10] TAAv7 3 Josh Poimboeuf
2019-10-22 18:39 ` [MODERATED] Re: [PATCH v7 10/10] TAAv7 10 Josh Poimboeuf
2019-10-23 7:24 ` Borislav Petkov
2019-10-22 21:20 ` [MODERATED] Re: [PATCH v7 04/10] TAAv7 4 Josh Poimboeuf
2019-10-22 21:35 ` Andrew Cooper
2019-10-22 21:44 ` Josh Poimboeuf
2019-10-22 22:03 ` Andrew Cooper
2019-10-23 1:16 ` Josh Poimboeuf
2019-10-23 15:46 ` [MODERATED] Re: [PATCH v7 00/10] TAAv7 0 Borislav Petkov
2019-10-23 17:11 ` Josh Poimboeuf
2019-10-23 21:49 ` Borislav Petkov
2019-10-23 22:12 ` Pawan Gupta
2019-10-24 14:08 ` Borislav Petkov
[not found] ` <5dae165e.1c69fb81.4beee.e271SMTPIN_ADDED_BROKEN@mx.google.com>
2019-10-24 20:53 ` [MODERATED] Re: [PATCH v7 06/10] TAAv7 6 Paolo Bonzini
2019-10-24 21:00 ` Luck, Tony
2019-10-24 21:33 ` Paolo Bonzini
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=20191023002756.GB30440@guptapadev.amr \
--to=pawan.kumar.gupta@linux.intel.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).