linux-kernel - Re: [PATCH 1/2] KVM: vmx, pmu: accept 0 for absent MSRs when host-initiated

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: <42261964-df72-879b-0166-8bbb8b0fc3df@redhat.com>
Date:   Wed, 1 Jun 2022 10:50:57 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Like Xu <like.xu.linux@...il.com>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH 1/2] KVM: vmx, pmu: accept 0 for absent MSRs when
 host-initiated

On 6/1/22 04:46, Like Xu wrote:
> On 1/6/2022 2:37 am, Sean Christopherson wrote:
>> On Tue, May 31, 2022, Paolo Bonzini wrote:
>>> Whenever an MSR is part of KVM_GET_MSR_INDEX_LIST, as is the case for
>>> MSR_IA32_DS_AREA, MSR_ARCH_LBR_DEPTH or MSR_ARCH_LBR_CTL, it has to be
>>> always settable with KVM_SET_MSR.  Accept a zero value for these MSRs
>>> to obey the contract.
> 
> Do we have a rule to decide whether to put MSRs into 
> KVM_GET_MSR_INDEX_LIST,
> for example a large number of LBR MSRs do not appear in it ?

In general I think it's much better to include them.  The only reason 
not to include them should be if the number of MSRs is variable and the 
actual number is accessible via KVM_GET_SUPPORTED_CPUID, a feature MSR, 
or KVM_CHECK_EXTENSION.

>> This is wrong, it will allow an unchecked wrmsrl() to 
>> MSR_ARCH_LBR_DEPTH if
>> X86_FEATURE_ARCH_LBR is not supported by hardware but userspace forces 
>> it in
>> guest CPUID.
> 
> What should we expect if the userspace forces guest to use features not 
> supported by KVM,
> especially the emulation of this feature depends on the functionality of 
> host and guest vcpu model ?

Certainly not a WARN or invalid vmwrite.

Paolo