If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
RTM and HLE features, it will affect TAA mitigation.
Signed-off-by: Peng Hao <[email protected]>
---
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);
return;
}
--
2.27.0
On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote:
> If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
> RTM and HLE features, it will affect TAA mitigation.
>
> Signed-off-by: Peng Hao <[email protected]>
> ---
> 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);
> return;
> }
How does that even happen - the hypervisor does not support the MSR but
"guest supports" TSX features?!
I guess the guest is detecting it wrong.
What hypervisor, what guest, how do I reproduce?
Please give full details.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Sep 6, 2021 at 5:30 PM Borislav Petkov <[email protected]> wrote:
>
> On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote:
> > If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
> > RTM and HLE features, it will affect TAA mitigation.
> >
> > Signed-off-by: Peng Hao <[email protected]>
> > ---
> > 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);
> > return;
> > }
>
> How does that even happen - the hypervisor does not support the MSR but
> "guest supports" TSX features?!
>
> I guess the guest is detecting it wrong.
>
> What hypervisor, what guest, how do I reproduce?
>
hypervisor is kvm, guest is linux too.
> Please give full details.
>
The host I used is kernel-5.4, and guest is kernel-5.13.
MSR_IA32_TSX_CTRL is exposed
to guest and guest to support RTM and HLE features, no direct
dependence. at the qemu I
started guest with -cpu host-model.
I have viewed the code of kernel-5.4, and MSR_IA32_TSX_CTRL is not
exposed to guest.
Thanks.
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
On 9/7/2021 9:47 AM, Hao Peng wrote:
> On Mon, Sep 6, 2021 at 5:30 PM Borislav Petkov <[email protected]> wrote:
>>
>> On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote:
>>> If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
>>> RTM and HLE features, it will affect TAA mitigation.
>>>
>>> Signed-off-by: Peng Hao <[email protected]>
>>> ---
>>> 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);
anyway, IMHO, we shouldn't do anything here for TAA. It should be in
taa_select_mitigation()
>>> return;
>>> }
>>
>> How does that even happen - the hypervisor does not support the MSR but
>> "guest supports" TSX features?!
>>
>> I guess the guest is detecting it wrong.
>>
>> What hypervisor, what guest, how do I reproduce?
>>
> hypervisor is kvm, guest is linux too.
>> Please give full details.
>>
> The host I used is kernel-5.4, and guest is kernel-5.13.
> MSR_IA32_TSX_CTRL is exposed
> to guest and guest to support RTM and HLE features, no direct
> dependence. at the qemu I
> started guest with -cpu host-model.
> I have viewed the code of kernel-5.4, and MSR_IA32_TSX_CTRL is not
> exposed to guest.
Does guest see TAA_NO bit?
> Thanks.
>> --
>> Regards/Gruss,
>> Boris.
>>
>> https://people.kernel.org/tglx/notes-about-netiquette
On Tue, Sep 7, 2021 at 10:08 AM Xiaoyao Li <[email protected]> wrote:
>
> On 9/7/2021 9:47 AM, Hao Peng wrote:
> > On Mon, Sep 6, 2021 at 5:30 PM Borislav Petkov <[email protected]> wrote:
> >>
> >> On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote:
> >>> If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
> >>> RTM and HLE features, it will affect TAA mitigation.
> >>>
> >>> Signed-off-by: Peng Hao <[email protected]>
> >>> ---
> >>> 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);
>
> anyway, IMHO, we shouldn't do anything here for TAA. It should be in
> taa_select_mitigation()
>
> >>> return;
> >>> }
> >>
> >> How does that even happen - the hypervisor does not support the MSR but
> >> "guest supports" TSX features?!
> >>
> >> I guess the guest is detecting it wrong.
> >>
> >> What hypervisor, what guest, how do I reproduce?
> >>
> > hypervisor is kvm, guest is linux too.
> >> Please give full details.
> >>
> > The host I used is kernel-5.4, and guest is kernel-5.13.
> > MSR_IA32_TSX_CTRL is exposed
> > to guest and guest to support RTM and HLE features, no direct
> > dependence. at the qemu I
> > started guest with -cpu host-model.
> > I have viewed the code of kernel-5.4, and MSR_IA32_TSX_CTRL is not
> > exposed to guest.
>
> Does guest see TAA_NO bit?
>
Guest can't see taa_no, which requires updating qemu to solve. But I think
there is a compatibility process here.
> > Thanks.
> >> --
> >> Regards/Gruss,
> >> Boris.
> >>
> >> https://people.kernel.org/tglx/notes-about-netiquette
>
On 9/7/2021 10:35 AM, Hao Peng wrote:
> On Tue, Sep 7, 2021 at 10:08 AM Xiaoyao Li <[email protected]> wrote:
>>
>> On 9/7/2021 9:47 AM, Hao Peng wrote:
>>> On Mon, Sep 6, 2021 at 5:30 PM Borislav Petkov <[email protected]> wrote:
>>>>
>>>> On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote:
>>>>> If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
>>>>> RTM and HLE features, it will affect TAA mitigation.
>>>>>
>>>>> Signed-off-by: Peng Hao <[email protected]>
>>>>> ---
>>>>> 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);
>>
>> anyway, IMHO, we shouldn't do anything here for TAA. It should be in
>> taa_select_mitigation()
>>
>>>>> return;
>>>>> }
>>>>
>>>> How does that even happen - the hypervisor does not support the MSR but
>>>> "guest supports" TSX features?!
>>>>
>>>> I guess the guest is detecting it wrong.
>>>>
>>>> What hypervisor, what guest, how do I reproduce?
>>>>
>>> hypervisor is kvm, guest is linux too.
>>>> Please give full details.
>>>>
>>> The host I used is kernel-5.4, and guest is kernel-5.13.
>>> MSR_IA32_TSX_CTRL is exposed
>>> to guest and guest to support RTM and HLE features, no direct
>>> dependence. at the qemu I
>>> started guest with -cpu host-model.
>>> I have viewed the code of kernel-5.4, and MSR_IA32_TSX_CTRL is not
>>> exposed to guest.
>>
>> Does guest see TAA_NO bit?
>>
> Guest can't see taa_no, which requires updating qemu to solve. But I think
> there is a compatibility process here.
Anyway, there should be some existing code in kernel already to handle
the case that CPUID reports TRM while MSR_IA32_CORE_CAPABILITIES doesn't
report MSR_TSX_CTRL nor TAA_NO.
And the Patch itself makes no sense.
>>> Thanks.
>>>> --
>>>> Regards/Gruss,
>>>> Boris.
>>>>
>>>> https://people.kernel.org/tglx/notes-about-netiquette
>>
On Tue, Sep 7, 2021 at 10:56 AM Xiaoyao Li <[email protected]> wrote:
>
> On 9/7/2021 10:35 AM, Hao Peng wrote:
> > On Tue, Sep 7, 2021 at 10:08 AM Xiaoyao Li <[email protected]> wrote:
> >>
> >> On 9/7/2021 9:47 AM, Hao Peng wrote:
> >>> On Mon, Sep 6, 2021 at 5:30 PM Borislav Petkov <[email protected]> wrote:
> >>>>
> >>>> On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote:
> >>>>> If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
> >>>>> RTM and HLE features, it will affect TAA mitigation.
> >>>>>
> >>>>> Signed-off-by: Peng Hao <[email protected]>
> >>>>> ---
> >>>>> 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);
> >>
> >> anyway, IMHO, we shouldn't do anything here for TAA. It should be in
> >> taa_select_mitigation()
> >>
> >>>>> return;
> >>>>> }
> >>>>
> >>>> How does that even happen - the hypervisor does not support the MSR but
> >>>> "guest supports" TSX features?!
> >>>>
> >>>> I guess the guest is detecting it wrong.
> >>>>
> >>>> What hypervisor, what guest, how do I reproduce?
> >>>>
> >>> hypervisor is kvm, guest is linux too.
> >>>> Please give full details.
> >>>>
> >>> The host I used is kernel-5.4, and guest is kernel-5.13.
> >>> MSR_IA32_TSX_CTRL is exposed
> >>> to guest and guest to support RTM and HLE features, no direct
> >>> dependence. at the qemu I
> >>> started guest with -cpu host-model.
> >>> I have viewed the code of kernel-5.4, and MSR_IA32_TSX_CTRL is not
> >>> exposed to guest.
> >>
> >> Does guest see TAA_NO bit?
> >>
> > Guest can't see taa_no, which requires updating qemu to solve. But I think
> > there is a compatibility process here.
>
> Anyway, there should be some existing code in kernel already to handle
> the case that CPUID reports TRM while MSR_IA32_CORE_CAPABILITIES doesn't
> report MSR_TSX_CTRL nor TAA_NO.
>
Can you point out which patches ? At present, guest is kernel-5.13
still has this problem.
Thanks.
> And the Patch itself makes no sense.
>
> >>> Thanks.
> >>>> --
> >>>> Regards/Gruss,
> >>>> Boris.
> >>>>
> >>>> https://people.kernel.org/tglx/notes-about-netiquette
> >>
>
On 9/7/2021 11:40 AM, Hao Peng wrote:
> On Tue, Sep 7, 2021 at 10:56 AM Xiaoyao Li <[email protected]> wrote:
>>
>> On 9/7/2021 10:35 AM, Hao Peng wrote:
>>> On Tue, Sep 7, 2021 at 10:08 AM Xiaoyao Li <[email protected]> wrote:
>>>>
>>>> On 9/7/2021 9:47 AM, Hao Peng wrote:
>>>>> On Mon, Sep 6, 2021 at 5:30 PM Borislav Petkov <[email protected]> wrote:
>>>>>>
>>>>>> On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote:
>>>>>>> If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
>>>>>>> RTM and HLE features, it will affect TAA mitigation.
>>>>>>>
>>>>>>> Signed-off-by: Peng Hao <[email protected]>
>>>>>>> ---
>>>>>>> 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);
>>>>
>>>> anyway, IMHO, we shouldn't do anything here for TAA. It should be in
>>>> taa_select_mitigation()
>>>>
>>>>>>> return;
>>>>>>> }
>>>>>>
>>>>>> How does that even happen - the hypervisor does not support the MSR but
>>>>>> "guest supports" TSX features?!
>>>>>>
>>>>>> I guess the guest is detecting it wrong.
>>>>>>
>>>>>> What hypervisor, what guest, how do I reproduce?
>>>>>>
>>>>> hypervisor is kvm, guest is linux too.
>>>>>> Please give full details.
>>>>>>
>>>>> The host I used is kernel-5.4, and guest is kernel-5.13.
>>>>> MSR_IA32_TSX_CTRL is exposed
>>>>> to guest and guest to support RTM and HLE features, no direct
>>>>> dependence. at the qemu I
>>>>> started guest with -cpu host-model.
>>>>> I have viewed the code of kernel-5.4, and MSR_IA32_TSX_CTRL is not
>>>>> exposed to guest.
>>>>
>>>> Does guest see TAA_NO bit?
>>>>
>>> Guest can't see taa_no, which requires updating qemu to solve. But I think
>>> there is a compatibility process here.
>>
>> Anyway, there should be some existing code in kernel already to handle
>> the case that CPUID reports TRM while MSR_IA32_CORE_CAPABILITIES doesn't
>> report MSR_TSX_CTRL nor TAA_NO.
>>
> Can you point out which patches ? At present, guest is kernel-5.13
> still has this problem.
What's the output of 'cat
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort' on your guest?
> Thanks.
>> And the Patch itself makes no sense.
>>
>>>>> Thanks.
>>>>>> --
>>>>>> Regards/Gruss,
>>>>>> Boris.
>>>>>>
>>>>>> https://people.kernel.org/tglx/notes-about-netiquette
>>>>
>>
On Tue, Sep 7, 2021 at 12:26 PM Xiaoyao Li <[email protected]> wrote:
>
> On 9/7/2021 11:40 AM, Hao Peng wrote:
> > On Tue, Sep 7, 2021 at 10:56 AM Xiaoyao Li <[email protected]> wrote:
> >>
> >> On 9/7/2021 10:35 AM, Hao Peng wrote:
> >>> On Tue, Sep 7, 2021 at 10:08 AM Xiaoyao Li <[email protected]> wrote:
> >>>>
> >>>> On 9/7/2021 9:47 AM, Hao Peng wrote:
> >>>>> On Mon, Sep 6, 2021 at 5:30 PM Borislav Petkov <[email protected]> wrote:
> >>>>>>
> >>>>>> On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote:
> >>>>>>> If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
> >>>>>>> RTM and HLE features, it will affect TAA mitigation.
> >>>>>>>
> >>>>>>> Signed-off-by: Peng Hao <[email protected]>
> >>>>>>> ---
> >>>>>>> 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);
> >>>>
> >>>> anyway, IMHO, we shouldn't do anything here for TAA. It should be in
> >>>> taa_select_mitigation()
> >>>>
> >>>>>>> return;
> >>>>>>> }
> >>>>>>
> >>>>>> How does that even happen - the hypervisor does not support the MSR but
> >>>>>> "guest supports" TSX features?!
> >>>>>>
> >>>>>> I guess the guest is detecting it wrong.
> >>>>>>
> >>>>>> What hypervisor, what guest, how do I reproduce?
> >>>>>>
> >>>>> hypervisor is kvm, guest is linux too.
> >>>>>> Please give full details.
> >>>>>>
> >>>>> The host I used is kernel-5.4, and guest is kernel-5.13.
> >>>>> MSR_IA32_TSX_CTRL is exposed
> >>>>> to guest and guest to support RTM and HLE features, no direct
> >>>>> dependence. at the qemu I
> >>>>> started guest with -cpu host-model.
> >>>>> I have viewed the code of kernel-5.4, and MSR_IA32_TSX_CTRL is not
> >>>>> exposed to guest.
> >>>>
> >>>> Does guest see TAA_NO bit?
> >>>>
> >>> Guest can't see taa_no, which requires updating qemu to solve. But I think
> >>> there is a compatibility process here.
> >>
> >> Anyway, there should be some existing code in kernel already to handle
> >> the case that CPUID reports TRM while MSR_IA32_CORE_CAPABILITIES doesn't
> >> report MSR_TSX_CTRL nor TAA_NO.
> >>
> > Can you point out which patches ? At present, guest is kernel-5.13
> > still has this problem.
>
> What's the output of 'cat
> /sys/devices/system/cpu/vulnerabilities/tsx_async_abort' on your guest?
>
Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown.
> > Thanks.
> >> And the Patch itself makes no sense.
> >>
> >>>>> Thanks.
> >>>>>> --
> >>>>>> Regards/Gruss,
> >>>>>> Boris.
> >>>>>>
> >>>>>> https://people.kernel.org/tglx/notes-about-netiquette
> >>>>
> >>
>
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 <[email protected]>
>---
> 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.
Thanks,
Pawan
On 07.09.2021 10:56, Xiaoyao Li wrote:
>On 9/7/2021 10:35 AM, Hao Peng wrote:
>>On Tue, Sep 7, 2021 at 10:08 AM Xiaoyao Li <[email protected]> wrote:
>>>
>>>On 9/7/2021 9:47 AM, Hao Peng wrote:
>>>>On Mon, Sep 6, 2021 at 5:30 PM Borislav Petkov <[email protected]> wrote:
>>>>>
>>>>>On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote:
>>>>>>If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
>>>>>>RTM and HLE features, it will affect TAA mitigation.
>>>>>>
>>>>>>Signed-off-by: Peng Hao <[email protected]>
>>>>>>---
>>>>>> 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);
>>>
>>>anyway, IMHO, we shouldn't do anything here for TAA. It should be in
>>>taa_select_mitigation()
>>>
>>>>>> return;
>>>>>> }
>>>>>
>>>>>How does that even happen - the hypervisor does not support the MSR but
>>>>>"guest supports" TSX features?!
>>>>>
>>>>>I guess the guest is detecting it wrong.
>>>>>
>>>>>What hypervisor, what guest, how do I reproduce?
>>>>>
>>>>hypervisor is kvm, guest is linux too.
>>>>>Please give full details.
>>>>>
>>>>The host I used is kernel-5.4, and guest is kernel-5.13.
>>>>MSR_IA32_TSX_CTRL is exposed
>>>>to guest and guest to support RTM and HLE features, no direct
>>>>dependence. at the qemu I
>>>>started guest with -cpu host-model.
>>>>I have viewed the code of kernel-5.4, and MSR_IA32_TSX_CTRL is not
>>>>exposed to guest.
>>>
>>>Does guest see TAA_NO bit?
>>>
>>Guest can't see taa_no, which requires updating qemu to solve. But I think
>>there is a compatibility process here.
>
>Anyway, there should be some existing code in kernel already to handle
>the case that CPUID reports TRM while MSR_IA32_CORE_CAPABILITIES
>doesn't report MSR_TSX_CTRL nor TAA_NO.
When TSX_CTRL MSR is not supported, TAA mitigation is same as MDS, and
it is deployed automatically provided the system has a recent microcode.
Thanks,
Pawan
On 07.09.2021 12:39, Hao Peng wrote:
>On Tue, Sep 7, 2021 at 12:26 PM Xiaoyao Li <[email protected]> wrote:
>>
>> On 9/7/2021 11:40 AM, Hao Peng wrote:
>> > On Tue, Sep 7, 2021 at 10:56 AM Xiaoyao Li <[email protected]> wrote:
>> >>
>> >> On 9/7/2021 10:35 AM, Hao Peng wrote:
>> >>> On Tue, Sep 7, 2021 at 10:08 AM Xiaoyao Li <[email protected]> wrote:
>> >>>>
>> >>>> On 9/7/2021 9:47 AM, Hao Peng wrote:
>> >>>>> On Mon, Sep 6, 2021 at 5:30 PM Borislav Petkov <[email protected]> wrote:
>> >>>>>>
>> >>>>>> On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote:
>> >>>>>>> If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
>> >>>>>>> RTM and HLE features, it will affect TAA mitigation.
>> >>>>>>>
>> >>>>>>> Signed-off-by: Peng Hao <[email protected]>
>> >>>>>>> ---
>> >>>>>>> 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);
>> >>>>
>> >>>> anyway, IMHO, we shouldn't do anything here for TAA. It should be in
>> >>>> taa_select_mitigation()
>> >>>>
>> >>>>>>> return;
>> >>>>>>> }
>> >>>>>>
>> >>>>>> How does that even happen - the hypervisor does not support the MSR but
>> >>>>>> "guest supports" TSX features?!
>> >>>>>>
>> >>>>>> I guess the guest is detecting it wrong.
>> >>>>>>
>> >>>>>> What hypervisor, what guest, how do I reproduce?
>> >>>>>>
>> >>>>> hypervisor is kvm, guest is linux too.
>> >>>>>> Please give full details.
>> >>>>>>
>> >>>>> The host I used is kernel-5.4, and guest is kernel-5.13.
>> >>>>> MSR_IA32_TSX_CTRL is exposed
>> >>>>> to guest and guest to support RTM and HLE features, no direct
>> >>>>> dependence. at the qemu I
>> >>>>> started guest with -cpu host-model.
>> >>>>> I have viewed the code of kernel-5.4, and MSR_IA32_TSX_CTRL is not
>> >>>>> exposed to guest.
>> >>>>
>> >>>> Does guest see TAA_NO bit?
>> >>>>
>> >>> Guest can't see taa_no, which requires updating qemu to solve. But I think
>> >>> there is a compatibility process here.
>> >>
>> >> Anyway, there should be some existing code in kernel already to handle
>> >> the case that CPUID reports TRM while MSR_IA32_CORE_CAPABILITIES doesn't
>> >> report MSR_TSX_CTRL nor TAA_NO.
>> >>
>> > Can you point out which patches ? At present, guest is kernel-5.13
>> > still has this problem.
>>
>> What's the output of 'cat
>> /sys/devices/system/cpu/vulnerabilities/tsx_async_abort' on your guest?
>>
>Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown.
This suggests that the microcode is old. Can you please share the output
of below cmds on host and guest:
$ grep . /sys/devices/system/cpu/vulnerabilities/*
$ lscpu
$ grep microcode /proc/cpuinfo | uniq
$ cat /proc/cmdline
Thanks,
Pawan
On Tue, Sep 7, 2021 at 1:13 PM Pawan Gupta
<[email protected]> 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 <[email protected]>
> >---
> > 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?
I made a mistake in the description before. This problem occurred
under the qemu -cpu Icelake-server .
When I debug this problem to -cpu host, the guest can see taa-no.
Thanks.
> Thanks,
> Pawan
On Tue, Sep 7, 2021 at 1:36 PM Pawan Gupta
<[email protected]> wrote:
>
> On 07.09.2021 12:39, Hao Peng wrote:
> >On Tue, Sep 7, 2021 at 12:26 PM Xiaoyao Li <[email protected]> wrote:
> >>
> >> On 9/7/2021 11:40 AM, Hao Peng wrote:
> >> > On Tue, Sep 7, 2021 at 10:56 AM Xiaoyao Li <[email protected]> wrote:
> >> >>
> >> >> On 9/7/2021 10:35 AM, Hao Peng wrote:
> >> >>> On Tue, Sep 7, 2021 at 10:08 AM Xiaoyao Li <[email protected]> wrote:
> >> >>>>
> >> >>>> On 9/7/2021 9:47 AM, Hao Peng wrote:
> >> >>>>> On Mon, Sep 6, 2021 at 5:30 PM Borislav Petkov <[email protected]> wrote:
> >> >>>>>>
> >> >>>>>> On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote:
> >> >>>>>>> If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
> >> >>>>>>> RTM and HLE features, it will affect TAA mitigation.
> >> >>>>>>>
> >> >>>>>>> Signed-off-by: Peng Hao <[email protected]>
> >> >>>>>>> ---
> >> >>>>>>> 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);
> >> >>>>
> >> >>>> anyway, IMHO, we shouldn't do anything here for TAA. It should be in
> >> >>>> taa_select_mitigation()
> >> >>>>
> >> >>>>>>> return;
> >> >>>>>>> }
> >> >>>>>>
> >> >>>>>> How does that even happen - the hypervisor does not support the MSR but
> >> >>>>>> "guest supports" TSX features?!
> >> >>>>>>
> >> >>>>>> I guess the guest is detecting it wrong.
> >> >>>>>>
> >> >>>>>> What hypervisor, what guest, how do I reproduce?
> >> >>>>>>
> >> >>>>> hypervisor is kvm, guest is linux too.
> >> >>>>>> Please give full details.
> >> >>>>>>
> >> >>>>> The host I used is kernel-5.4, and guest is kernel-5.13.
> >> >>>>> MSR_IA32_TSX_CTRL is exposed
> >> >>>>> to guest and guest to support RTM and HLE features, no direct
> >> >>>>> dependence. at the qemu I
> >> >>>>> started guest with -cpu host-model.
> >> >>>>> I have viewed the code of kernel-5.4, and MSR_IA32_TSX_CTRL is not
> >> >>>>> exposed to guest.
> >> >>>>
> >> >>>> Does guest see TAA_NO bit?
> >> >>>>
> >> >>> Guest can't see taa_no, which requires updating qemu to solve. But I think
> >> >>> there is a compatibility process here.
> >> >>
> >> >> Anyway, there should be some existing code in kernel already to handle
> >> >> the case that CPUID reports TRM while MSR_IA32_CORE_CAPABILITIES doesn't
> >> >> report MSR_TSX_CTRL nor TAA_NO.
> >> >>
> >> > Can you point out which patches ? At present, guest is kernel-5.13
> >> > still has this problem.
> >>
> >> What's the output of 'cat
> >> /sys/devices/system/cpu/vulnerabilities/tsx_async_abort' on your guest?
> >>
> >Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown.
>
> This suggests that the microcode is old. Can you please share the output
> of below cmds on host and guest:
>
> $ grep . /sys/devices/system/cpu/vulnerabilities/*
host : not affected
guest: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host
state unknown.
> $ lscpu
> $ grep microcode /proc/cpuinfo | uniq
host: microcode : 0xd000250
guest: microcode : 0x1
> $ cat /proc/cmdline
There are no command line parameters for tsx both host and guest.
>
> Thanks,
> Pawan
On 07.09.2021 14:56, Hao Peng wrote:
>On Tue, Sep 7, 2021 at 1:36 PM Pawan Gupta
><[email protected]> wrote:
>>
>> On 07.09.2021 12:39, Hao Peng wrote:
>> >On Tue, Sep 7, 2021 at 12:26 PM Xiaoyao Li <[email protected]> wrote:
>> >>
>> >> On 9/7/2021 11:40 AM, Hao Peng wrote:
>> >> > On Tue, Sep 7, 2021 at 10:56 AM Xiaoyao Li <[email protected]> wrote:
>> >> >>
>> >> >> On 9/7/2021 10:35 AM, Hao Peng wrote:
>> >> >>> On Tue, Sep 7, 2021 at 10:08 AM Xiaoyao Li <[email protected]> wrote:
>> >> >>>>
>> >> >>>> On 9/7/2021 9:47 AM, Hao Peng wrote:
>> >> >>>>> On Mon, Sep 6, 2021 at 5:30 PM Borislav Petkov <[email protected]> wrote:
>> >> >>>>>>
>> >> >>>>>> On Mon, Sep 06, 2021 at 10:46:05AM +0800, Hao Peng wrote:
>> >> >>>>>>> If hypervisor does not support MSR_IA32_TSX_CTRL, but guest supports
>> >> >>>>>>> RTM and HLE features, it will affect TAA mitigation.
>> >> >>>>>>>
>> >> >>>>>>> Signed-off-by: Peng Hao <[email protected]>
>> >> >>>>>>> ---
>> >> >>>>>>> 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);
>> >> >>>>
>> >> >>>> anyway, IMHO, we shouldn't do anything here for TAA. It should be in
>> >> >>>> taa_select_mitigation()
>> >> >>>>
>> >> >>>>>>> return;
>> >> >>>>>>> }
>> >> >>>>>>
>> >> >>>>>> How does that even happen - the hypervisor does not support the MSR but
>> >> >>>>>> "guest supports" TSX features?!
>> >> >>>>>>
>> >> >>>>>> I guess the guest is detecting it wrong.
>> >> >>>>>>
>> >> >>>>>> What hypervisor, what guest, how do I reproduce?
>> >> >>>>>>
>> >> >>>>> hypervisor is kvm, guest is linux too.
>> >> >>>>>> Please give full details.
>> >> >>>>>>
>> >> >>>>> The host I used is kernel-5.4, and guest is kernel-5.13.
>> >> >>>>> MSR_IA32_TSX_CTRL is exposed
>> >> >>>>> to guest and guest to support RTM and HLE features, no direct
>> >> >>>>> dependence. at the qemu I
>> >> >>>>> started guest with -cpu host-model.
>> >> >>>>> I have viewed the code of kernel-5.4, and MSR_IA32_TSX_CTRL is not
>> >> >>>>> exposed to guest.
>> >> >>>>
>> >> >>>> Does guest see TAA_NO bit?
>> >> >>>>
>> >> >>> Guest can't see taa_no, which requires updating qemu to solve. But I think
>> >> >>> there is a compatibility process here.
>> >> >>
>> >> >> Anyway, there should be some existing code in kernel already to handle
>> >> >> the case that CPUID reports TRM while MSR_IA32_CORE_CAPABILITIES doesn't
>> >> >> report MSR_TSX_CTRL nor TAA_NO.
>> >> >>
>> >> > Can you point out which patches ? At present, guest is kernel-5.13
>> >> > still has this problem.
>> >>
>> >> What's the output of 'cat
>> >> /sys/devices/system/cpu/vulnerabilities/tsx_async_abort' on your guest?
>> >>
>> >Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown.
>>
>> This suggests that the microcode is old. Can you please share the output
>> of below cmds on host and guest:
>>
>> $ grep . /sys/devices/system/cpu/vulnerabilities/*
>host : not affected
>guest: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host
>state unknown.
This would mean TAA_NO is not being exported to guest. Most likely qemu
needs to be patched for the CPU configuration you are using.
Thanks,
Pawan
On 07.09.2021 14:36, Hao Peng wrote:
>On Tue, Sep 7, 2021 at 1:13 PM Pawan Gupta
><[email protected]> 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 <[email protected]>
>> >---
>> > 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 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".
>When I debug this problem to -cpu host, the guest can see taa-no.
>Thanks.
Thats good.
On Wed, Sep 8, 2021 at 6:57 AM Pawan Gupta
<[email protected]> wrote:
>
> On 07.09.2021 14:36, Hao Peng wrote:
> >On Tue, Sep 7, 2021 at 1:13 PM Pawan Gupta
> ><[email protected]> 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 <[email protected]>
> >> >---
> >> > 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.
On 08.09.2021 13:06, Hao Peng wrote:
>On Wed, Sep 8, 2021 at 6:57 AM Pawan Gupta
><[email protected]> wrote:
>>
>> On 07.09.2021 14:36, Hao Peng wrote:
>> >On Tue, Sep 7, 2021 at 1:13 PM Pawan Gupta
>> ><[email protected]> 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 <[email protected]>
>> >> >---
>> >> > 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.