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
