linux-kernel - Re: [PATCH] x86/tsx: Use MSR_TSX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220216003950.5jxecuf773g2kuwl@guptapa-mobl1.amr.corp.intel.com>
Date:   Tue, 15 Feb 2022 16:39:50 -0800
From:   Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Andrew Cooper <andrew.cooper3@...rix.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, Andi Kleen <ak@...ux.intel.com>,
        Tony Luck <tony.luck@...el.com>, linux-kernel@...r.kernel.org,
        antonio.gomez.iglesias@...ux.intel.com, neelima.krishnan@...el.com,
        stable@...r.kernel.org
Subject: Re: [PATCH] x86/tsx: Use MSR_TSX_CTRL to clear CPUID bits

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