linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <Andrew.Cooper3@citrix.com>
To: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Borislav Petkov <bp@alien8.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"x86@kernel.org" <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" <linux-kernel@vger.kernel.org>,
	"antonio.gomez.iglesias@linux.intel.com" 
	<antonio.gomez.iglesias@linux.intel.com>,
	"neelima.krishnan@intel.com" <neelima.krishnan@intel.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] x86/tsx: Use MSR_TSX_CTRL to clear CPUID bits
Date: Wed, 16 Feb 2022 00:49:05 +0000	[thread overview]
Message-ID: <6724088f-c7cf-da92-e894-d8970f13bf1e@citrix.com> (raw)
In-Reply-To: <20220216003950.5jxecuf773g2kuwl@guptapa-mobl1.amr.corp.intel.com>

On 16/02/2022 00:39, Pawan Gupta wrote:
> 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.

The purpose of setting RTM_ALLOW isn't to enable TSX per say.

The purpose is to make MSR_TSX_CTRL.RTM_DISABLE behaves consistently on
all hardware, which reduces the complexity and invasiveness of dealing
with this special case, because the TAA workaround will still turn TSX
off by default.

The configuration you don't want to be running with is RTM_ALLOW &&
!RTM_DISABLE, because that is "still vulnerable to TSX Async Abort".

~Andrew

  reply	other threads:[~2022-02-16  0:50 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
2022-02-16  0:49                     ` Andrew Cooper [this message]
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=6724088f-c7cf-da92-e894-d8970f13bf1e@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=ak@linux.intel.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=pawan.kumar.gupta@linux.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).