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]
Message-ID: <c71894e8-d6ee-9a2d-3054-5d4df61fe122@redhat.com>
Date:   Tue, 25 Oct 2022 23:31:26 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        jmattson@...gle.com
Subject: Re: [PATCH] KVM: x86: Do not expose the host value of CPUID.8000001EH

On 10/25/22 23:25, Sean Christopherson wrote:
>> 0xb and 0x1f are already special cased because EDX is set to the X2APIC id.
>> KVM knows how to do that unlike the NodeId and CoreId.
> But KVM doesn't properly support 0xB/0x1F.  E.g. if usersepace regurgitates
> KVM_GET_SUPPORTED_CPUID back into KVM_SET_CPUID2, all vCPUs will observe the same
> x2APIC ID in EDX, and it will be a host x2APIC ID to boot.
> 
> KVM only handles the where userspace provides 0xB.1 (or 0x1F.1), the guest performs
> CPUID with ECX>1,_and_  userspace doesn't provide the exact CPUID entry.

Ah, you're right - I confused it with the "undefined leaves" behavior here:

         } else {
                 *eax = *ebx = *ecx = *edx = 0;
                 /*
                  * When leaf 0BH or 1FH is defined, CL is pass-through
                  * and EDX is always the x2APIC ID, even for undefined
                  * subleaves. Index 1 will exist iff the leaf is
                  * implemented, so we pass through CL iff leaf 1
                  * exists. EDX can be copied from any existing index.
                  */
                 if (function == 0xb || function == 0x1f) {
                         entry = kvm_find_cpuid_entry(vcpu, function, 1);
                         if (entry) {
                                 *ecx = index & 0xff;
                                 *edx = entry->edx;
                         }
                 }
         }

but KVM in principle could set EDX to the right value for 0xB and 0x1F, 
the x2APIC ID is available for the kernel LAPIC case.  0x8000001e cannot 
be fixed up the same way.

> I suppose one could argue that KVM needs to communicate to userspace that KVM
> emulates the edge case behavior of CPUID 0xB and 0x1F, but I would argue that KVM
> communicates that by announcing a max basic leaf >= 0xB/0x1F.

I agree (or we could fix it up automagically if so inclined).  Either 
way it should be documented at the end of api.rst.

Paolo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ