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]
Date:   Fri, 31 Jan 2020 12:57:51 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Xiaoyao Li <xiaoyao.li@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Paolo Bonzini <pbonzini@...hat.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: VMX: Extend VMX's #AC handding




> On Jan 31, 2020, at 12:18 PM, Sean Christopherson <sean.j.christopherson@...el.com> wrote:
> 
> On Sat, Feb 01, 2020 at 01:47:10AM +0800, Xiaoyao Li wrote:
>>> On 1/31/2020 11:37 PM, Andy Lutomirski wrote:
>>> 
>>>> On Jan 30, 2020, at 11:22 PM, Xiaoyao Li <xiaoyao.li@...el.com> wrote:
>>>> 
>>>> On 1/31/2020 1:16 AM, Andy Lutomirski wrote:
> 
> ...
> 
>>>>> Can we get a credible description of how this would work? I suggest: Intel
>>>>> adds and documents a new CPUID bit or core capability bit that means
>>>>> “split lock detection is forced on”.  If this bit is set, the MSR bit
>>>>> controlling split lock detection is still writable, but split lock
>>>>> detection is on regardless of the value.  Operating systems are expected
>>>>> to set the bit to 1 to indicate to a hypervisor, if present, that they
>>>>> understand that split lock detection is on.  This would be an SDM-only
>>>>> change, but it would also be a commitment to certain behavior for future
>>>>> CPUs that don’t implement split locks.
>>>> 
>>>> It sounds a PV solution for virtualization that it doesn't need to be
>>>> defined in Intel-SDM but in KVM document.
>>>> 
>>>> As you suggested, we can define new bit in KVM_CPUID_FEATURES (0x40000001)
>>>> as KVM_FEATURE_SLD_FORCED and reuse MSR_TEST_CTL or use a new virtualized
>>>> MSR for guest to tell hypervisor it understand split lock detection is
>>>> forced on.
>>> 
>>> Of course KVM can do this. But this missed the point. Intel added a new CPU
>>> feature, complete with an enumeration mechanism, that cannot be correctly
>>> used if a hypervisor is present.
>> 
>> Why it cannot be correctly used if a hypervisor is present? Because it needs
>> to disable split lock detection when running a vcpu for guest as this patch
>> wants to do?
> 
> Because SMT.  Unless vCPUs are pinned 1:1 with pCPUs, and the guest is
> given an accurate topology, disabling/enabling split-lock #AC may (or may
> not) also disable/enable split-lock #AC on a random vCPU in the guest.
> 
>>> As it stands, without specific hypervisor and guest support of a non-Intel
>>> interface, it is *impossible* to give architecturally correct behavior to a
>>> guest. If KVM implements your suggestion, *Windows* guests will still
>>> malfunction on Linux.
>> 
>> Actually, KVM don't need to implement my suggestion. It can just virtualize
>> and expose this feature (MSR_IA32_CORE_CAPABILITIES and MSR_TEST_CTRL) to
>> guest, (but it may have some requirement that HT is disabled and host is
>> sld_off) then guest can use it architecturally.
> 
> This is essentially what I proposed a while back.  KVM would allow enabling
> split-lock #AC in the guest if and only if SMT is disabled or the enable bit
> is per-thread, *or* the host is in "warn" mode (can live with split-lock #AC
> being randomly disabled/enabled) and userspace has communicated to KVM that
> it is pinning vCPUs.

How about covering the actual sensible case: host is set to fatal?  In this mode, the guest gets split lock detection whether it wants it or not. How do we communicate this to the guest?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ