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: <d22e9a18-14eb-8214-976a-72b76edb0dc3@intel.com>
Date:   Thu, 21 May 2020 16:03:07 +0800
From:   Xiaoyao Li <xiaoyao.li@...el.com>
To:     Maxim Levitsky <mlevitsk@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] kvm/x86: don't expose MSR_IA32_UMWAIT_CONTROL
 unconditionally

On 5/21/2020 12:56 AM, Maxim Levitsky wrote:
> On Wed, 2020-05-20 at 18:33 +0200, Vitaly Kuznetsov wrote:
>> Maxim Levitsky <mlevitsk@...hat.com> writes:
>>
>>> This msr is only available when the host supports WAITPKG feature.
>>>
>>> This breaks a nested guest, if the L1 hypervisor is set to ignore
>>> unknown msrs, because the only other safety check that the
>>> kernel does is that it attempts to read the msr and
>>> rejects it if it gets an exception.
>>>
>>> Fixes: 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL
>>>
>>> Signed-off-by: Maxim Levitsky <mlevitsk@...hat.com>
>>> ---
>>>   arch/x86/kvm/x86.c | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index fe3a24fd6b263..9c507b32b1b77 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)
>>>   			if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
>>>   			    min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp))
>>>   				continue;
>>> +			break;
>>> +		case MSR_IA32_UMWAIT_CONTROL:
>>> +			if (!kvm_cpu_cap_has(X86_FEATURE_WAITPKG))
>>> +				continue;
>>
>> I'm probably missing something but (if I understand correctly) the only
>> effect of dropping MSR_IA32_UMWAIT_CONTROL from msrs_to_save would be
>> that KVM userspace won't see it in e.g. KVM_GET_MSR_INDEX_LIST. But why
>> is this causing an issue? I see both vmx_get_msr()/vmx_set_msr() have
>> 'host_initiated' check:
>>
>>         case MSR_IA32_UMWAIT_CONTROL:
>>                  if (!msr_info->host_initiated && !vmx_has_waitpkg(vmx))
>>                          return 1;
> 
> Here it fails like that:
> 
> 1. KVM_GET_MSR_INDEX_LIST returns this msrs, and qemu notes that
>     it is supported in 'has_msr_umwait' global var

In general, KVM_GET_MSR_INDEX_LIST won't return MSR_IA32_UMWAIT_CONTROL 
if KVM cannot read this MSR, see kvm_init_msr_list().

You hit issue because you used "ignore_msrs".



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ