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: <c3b916c2-5b4e-31d1-b27b-bf71b621bd7b@redhat.com>
Date:   Mon, 8 Feb 2021 11:31:36 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     "Xu, Like" <like.xu@...el.com>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Like Xu <like.xu@...ux.intel.com>
Subject: Re: [PATCH v2 4/4] KVM: x86: Expose Architectural LBR CPUID and its
 XSAVES bit

On 07/02/21 02:02, Xu, Like wrote:
> On 2021/2/5 19:00, Paolo Bonzini wrote:
>> On 05/02/21 09:16, Xu, Like wrote:
>>> Hi Paolo,
>>>
>>> I am wondering if it is acceptable for you to
>>> review the minor Architecture LBR patch set without XSAVES for v5.12 ?
>>>
>>> As far as I know, the guest Arch LBR  can still work without XSAVES 
>>> support.
>>
>> I dopn't think it can work.  You could have two guests on the same 
>> physical CPU and the MSRs would be corrupted if the guests write to 
>> the MSR but they do not enable the LBRs.
>>
>> Paolo
>>
> Neither Arch LBR nor the old version of LBR have this corruption issue,
> and we will not use XSAVES for at least LBR MSRs in the VMX transaction.
> 
> This is because we have reused the LBR save/restore swicth support from the
> host perf mechanism in the legacy LBR support, which will save/restore 
> the LBR
> MSRs of the vcpu (thread) when the vcpu is sched in/out.
> 
> Therefore, if we have two guests on the same physical CPU, the usage of 
> LBR MSRs
> is isolated, and it's also true when we use LBR to trace the hypervisor 
> on the host.
> The same thing happens on the platforms which supports Arch LBR.
> 
> I propose that we don't support using XSAVES to save/restore Arch LRB 
> *in the guest*
> (just like the guest Intel PT), but use the traditional RD/WRMSR, which 
> still works
> like the legacy LBR.

Ok, this makes sense.  I'll review the patches more carefully, looking 
at 5.13 for the target.

Paolo

> Since we already have legacy LBR support, we can add a small amount of 
> effort (just
> two more MSRs emulation and related CPUID exposure) to support Arch LBR 
> w/o XSAVES.
> 
> I estimate that there are many issues we need to address when we 
> supporting guests
> to use xsaves instructions. As a rational choice, we could enable the 
> basic Arch LBR.
> 
> Paolo and Sean, what do you think ?
> 
> ---
> thx, likexu
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ