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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPm50aLFvP=F6Lz9M-a5aNcrx+cEkAZ6NPWwEShEx2yKk64c_g@mail.gmail.com>
Date:   Wed, 8 Sep 2021 13:06:44 +0800
From:   Hao Peng <flyingpenghao@...il.com>
To:     Pawan Gupta <pawan.kumar.gupta@...ux.intel.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 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?
> >I made a mistake in the description before. This problem occurred
> >under the qemu -cpu Icelake-server .
>
> So looks like the real problem is with qemu feature definitions for
> cpu "Icelake-Server", it is probably not exporting "taa-no".
>
Yes, I already know the reason, but because it is inconvenient to
update the version of
the host component, consider the guest compatibility method.
> >When I debug this problem to -cpu host, the guest can see taa-no.
> >Thanks.
>
> Thats good.