That seems to be the consensus of recommendations, on top of updating to the latest patches and firmware for MDS vulnerabilities, not only for Windows, but all OS's on top of Intel CPU's: CVE-2019-11135 - Transactional Synchronization Extensions (TSX) Asynchronous Abort Updated Yesterday at 6:34 AM https://access.redhat.com/articles/tsx-asynchronousabort "...One way of mitigating TAA issue is to disable TSX feature of the CPU, so that TSX Asynchronous Abort (TAA) would not occur, and in turn the said information leakage via speculative side channel would not occur. The kernel update introduces a new kernel boot parameter ‘tsx=on/off/auto’ to enable OR disable CPU’s Transactional Synchronization Extensions (TSX) feature. It requires microcode updates to be installed. tsx=on Enable the TSX feature <= **RHEL Default** tsx=off Disable the TSX feature tsx=auto Disable TSX if CPU is affected, else enable TSX" Intel says the same thing many times within a number of documents, but couches it within many layers of situational caveats: Intel® Transactional Synchronization Extensions (Intel® TSX) Asynchronous Abort / CVE-2019-11135 / INTEL-SA-00270 https://software.intel.com/security...ation-extensions-intel-tsx-asynchronous-abort "On CPUs that do not require software MDS mitigations (IA32_ARCH_CAPABILITIES [MDS_NO]=1), TAA can be mitigated by either applying the MDS software mitigations or by selectively disabling Intel TSX for the workload using the IA32_TSX_CTRL MSR. Refer to Deep Dive: Intel® Transactional Synchronization Extensions (Intel® TSX) Asynchronous Abort for more details. ... To help prevent possibly malicious guest VMs from using Intel TSX when it is not enumerated to them, VMMs should set IA32_TSX_CTRL[RTM_DISABLE] (bit 0) to disable Intel TSX on processors affected by TAA that are running untrusted guest VMs. VMMs should ensure they apply the mitigations described in theMDS disclosure to guest VMs for which Intel TSX is enabled (IA32_TSX_CTRL[RTM_DISABLE] (bit 0)=0). Specifically, the VMM should ensure that sensitive data is not in the affected buffers before entering possibly malicious Intel TSX-enabled guests (for example, by executing VERW). The VMM should also ensure that possible victim VMs are not running on the sibling logical processor as untrusted guests." Start here to find new vulnerabilities at Intel, and follow potential links - you'll arrive at the crucial info several times within a number of documents if you follow the rabbit hole ad infinitum in call-backs as well as external references: Software Guidance for Security Advisories https://software.intel.com/security-software-guidance/software-guidance Even deeper diving: Deep Dive: Intel® Transactional Synchronization Extensions (Intel® TSX) Asynchronous Abort https://software.intel.com/security...ation-extensions-intel-tsx-asynchronous-abort Lots there to digest, start by searching for every instance of "disa" - not only TSX but also RTM and others. Intel isn't "there yet" with TSX like they are with recommending disabling "hyperthreading" everywhere as the more general rule for being secure without having to delve deeply into the situational limitations - requiring you to dig out the details and decide whether to leave it enabled or disable Hyperthreading / TSX. And, note there are microcode updates required for the disable in the OS to be effective. Same goes for legacy software that may use the CPUID to determine functionality, look for changing CPUID.