From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Andi Kleen <ak@linux.intel.com>, Tony Luck <tony.luck@intel.com>,
linux-kernel@vger.kernel.org,
antonio.gomez.iglesias@linux.intel.com,
neelima.krishnan@intel.com, stable@vger.kernel.org
Subject: Re: [PATCH] x86/tsx: Use MSR_TSX_CTRL to clear CPUID bits
Date: Tue, 15 Feb 2022 16:39:50 -0800 [thread overview]
Message-ID: <20220216003950.5jxecuf773g2kuwl@guptapa-mobl1.amr.corp.intel.com> (raw)
In-Reply-To: <YgwAHU7gCnik8Kv6@zn.tnic>
On 15.02.2022 20:33, Borislav Petkov wrote:
>On Tue, Feb 15, 2022 at 10:19:31AM -0800, Pawan Gupta wrote:
>> I admit it has gotten complicated with so many bits associated with TSX.
>
>Yah, and looka here:
>
>https://github.com/andyhhp/xen/commit/ad9f7c3b2e0df38ad6d54f4769d4dccf765fbcee
>
>It seems it isn't complicated enough. ;-\
>
>Andy just made me aware of this thing where you guys have added a new
>MSR bit:
>
>MSR_MCU_OPT_CTRL[1] which is called something like
>MCU_OPT_CTRL_RTM_ALLOW or so.
RTM_ALLOW bit was added to MSR_MCU_OPT_CTRL, but its not set by default,
and it is *not* recommended to be used in production deployments [1]:
Although MSR 0x122 (TSX_CTRL) and MSR 0x123 (IA32_MCU_OPT_CTRL) can be
used to reenable Intel TSX for development, doing so is not recommended
for production deployments. In particular, applying MD_CLEAR flows for
mitigation of the Intel TSX Asynchronous Abort (TAA) transient execution
attack may not be effective on these processors when Intel TSX is
enabled with updated microcode. The processors continue to be mitigated
against TAA when Intel TSX is disabled.
> And lemme quote from that patch:
>
> /*
> * Probe for the February 2022 microcode which de-features TSX on
> * TAA-vulnerable client parts - WHL-R/CFL-R.
> *
> * RTM_ALWAYS_ABORT (read above) enumerates the new functionality,
> * but is read as zero if MCU_OPT_CTRL.RTM_ALLOW has been set
> * before we run. Undo this.
> */
Such development-only bit (SDV_ENABLE_RTM) existed for previous round of
TSX defeature, but we decided not to use it:
https://lore.kernel.org/lkml/20210611232114.3dmmkpkkcqg5orhw@gupta-dev2.localdomain/
I am not sure why do we need to handle RTM_ALLOW this time? I will
update the patch if you think otherwise.
Thanks,
Pawan
[1] Intel Transactional Synchronization Extension (Intel TSX) Disable Update for Selected Processors
https://cdrdv2.intel.com/v1/dl/getContent/643557
>so MCU_OPT_CTRL.RTM_ALLOW=1 would have
>CPUID.X86_FEATURE_RTM_ALWAYS_ABORT=0, which means, we cannot tie TSX disabling on
>X86_FEATURE_RTM_ALWAYS_ABORT only.
>
>So this would need more work, it seems to me.
>
>Thx.
>
>--
>Regards/Gruss,
> Boris.
>
>https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2022-02-16 0:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-09 21:04 [PATCH] x86/tsx: Use MSR_TSX_CTRL to clear CPUID bits Pawan Gupta
2022-02-14 17:38 ` Borislav Petkov
2022-02-14 22:41 ` Pawan Gupta
2022-02-14 23:28 ` Borislav Petkov
2022-02-15 0:20 ` Pawan Gupta
2022-02-15 10:24 ` Borislav Petkov
2022-02-15 12:11 ` Pawan Gupta
2022-02-15 16:31 ` Borislav Petkov
2022-02-15 18:19 ` Pawan Gupta
2022-02-15 19:33 ` Borislav Petkov
2022-02-16 0:39 ` Pawan Gupta [this message]
2022-02-16 0:49 ` Andrew Cooper
2022-02-16 1:28 ` Pawan Gupta
2022-02-16 6:08 ` Pawan Gupta
2022-02-16 10:30 ` Borislav Petkov
2022-02-16 19:03 ` Pawan Gupta
2022-02-16 11:46 ` Andrew Cooper
2022-02-16 18:59 ` Pawan Gupta
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=20220216003950.5jxecuf773g2kuwl@guptapa-mobl1.amr.corp.intel.com \
--to=pawan.kumar.gupta@linux.intel.com \
--cc=ak@linux.intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=antonio.gomez.iglesias@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=neelima.krishnan@intel.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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).