linux-kernel - Re: [PATCH] x86/tsx: clear RTM and HLE when MSR_IA32_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] [day] [month] [year] [list]

Date:   Wed, 8 Sep 2021 09:02:06 -0700
From:   Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To:     Hao Peng <flyingpenghao@...il.com>
Cc:     tglx@...utronix.de, mingo@...hat.com,
        Borislav Petkov <bp@...en8.de>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/tsx: clear RTM and HLE when MSR_IA32_TSX_CTRL is not
 supported

On 08.09.2021 13:06, Hao Peng wrote:
>On Wed, Sep 8, 2021 at 6:57 AM Pawan Gupta
><pawan.kumar.gupta@...ux.intel.com> wrote:
>>
>> On 07.09.2021 14:36, Hao Peng wrote:
>> >On Tue, Sep 7, 2021 at 1:13 PM Pawan Gupta
>> ><pawan.kumar.gupta@...ux.intel.com> wrote:
>> >>
>> >> On 06.09.2021 10:46, Hao Peng wrote:
>> >> >If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
>> >> >RTM and HLE features, it will affect TAA mitigation.
>> >>
>> >> Guests are on purpose not allowed to control TSX via MSR_IA32_TSX_CTRL,
>> >> otherwise a malicious guest can enable TSX and attack host or other
>> >> guests. The TAA mitigation within a guest is same as MDS i.e.
>> >> micro-architectural buffer clear using VERW instruction. Support for
>> >> VERW is added by the microcode update and enumerate by
>> >> MSR_ARCH_CAP[MD_CLEAR] bit.
>> >>
>> >> >Signed-off-by: Peng Hao <flyingpeng@...cent.com>
>> >> >---
>> >> > arch/x86/kernel/cpu/tsx.c | 7 +++++++
>> >> > 1 file changed, 7 insertions(+)
>> >> >
>> >> >diff --git a/arch/x86/kernel/cpu/tsx.c b/arch/x86/kernel/cpu/tsx.c
>> >> >index 9c7a5f049292..5e852c14fef2 100644
>> >> >--- a/arch/x86/kernel/cpu/tsx.c
>> >> >+++ b/arch/x86/kernel/cpu/tsx.c
>> >> >@@ -122,6 +122,13 @@ void __init tsx_init(void)
>> >> >
>> >> >        if (!tsx_ctrl_is_supported()) {
>> >> >                tsx_ctrl_state = TSX_CTRL_NOT_SUPPORTED;
>> >> >+
>> >> >+               /* If hypervisor does not support MSR_IA32_TSX_CTRL emulation,
>> >> >+                * but guest supports RTM and HLE features, it will affect TAA
>> >> >+                * （tsx_async_abort）mitigation.
>> >> >+                */
>> >> >+               setup_clear_cpu_cap(X86_FEATURE_RTM);
>> >> >+               setup_clear_cpu_cap(X86_FEATURE_HLE);
>> >>
>> >> This is not correct. TSX feature can exist without TSX_CTRL MSR.
>> >> Moreover, clearing the cached bits with setup_clear_cpu_cap() doesn't
>> >> disable the TSX feature in CPU.
>> >>
>> >After applying this patch, the output of
>> >/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
>> >becomes “Mitigation: TSX disabled”.Do you mean that tsx is still
>> >enabled in this case in guest?
>>
>> If the host has TSX enabled, guest can use TSX instructions irrespective
>> of what cpu capabilities in the guest says.
>>
>I understand that guest cannot produce any actual effects on the hardware,
>so if the host has resolved the TAA bug on the hardware, does the guest actually
>have no vulnerability no matter what TAA status is displayed?

Yes, if the host does not have TAA bug, guest also does not have it.