On 16.02.2022 00:49, Andrew Cooper wrote:
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".
I am not sure how a system can end up with RTM_ALLOW && !RTM_DISABLE? I
have no problem taking care of this case, I am just debating why we need
it.
One way to get to this state is BIOS sets RTM_ALLOW (dont know why?) and
linux cmdline has tsx=on.
Thanks,
Pawan
