From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hildenbrand Subject: Re: [PATCH] kvm: vmx: Raise #UD on unsupported RDSEED Date: Mon, 21 Aug 2017 15:00:57 +0200 Message-ID: <551fa98c-2898-87a7-5e8b-96f2f463f182@redhat.com> References: <20170818184310.117806-1-jmattson@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: Jim Mattson , kvm@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:43012 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753110AbdHUNA7 (ORCPT ); Mon, 21 Aug 2017 09:00:59 -0400 In-Reply-To: <20170818184310.117806-1-jmattson@google.com> Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: On 18.08.2017 20:43, Jim Mattson wrote: > A guest may not be configured to support RDSEED, even when the host > does. If the guest does not support RDSEED, intercept the instruction > and synthesize #UD. Would the same also hold for nVMX guests? I think if our L1 CPU does not have RSEED, then also the L2 CPU should not be allowed to use it. @@ -10371,6 +10371,7 @@ static int prepare_vmcs02(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12, SECONDARY_EXEC_RDTSCP | SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY | SECONDARY_EXEC_APIC_REGISTER_VIRT | + SECONDARY_EXEC_RDSEED_EXITING | SECONDARY_EXEC_ENABLE_VMFUNC); if (nested_cpu_has(vmcs12, CPU_BASED_ACTIVATE_SECONDARY_CONTROLS)) { and maybe also +++ b/arch/x86/kvm/vmx.c @@ -2811,6 +2811,7 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx *vmx) SECONDARY_EXEC_RDRAND | SECONDARY_EXEC_RDSEED | SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES | SECONDARY_EXEC_RDTSCP | + SECONDARY_EXEC_RDSEED_EXITING | SECONDARY_EXEC_DESC | SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE | SECONDARY_EXEC_APIC_REGISTER_VIRT | (but I always get confused about the level of filtering) > --- > arch/x86/kvm/vmx.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > index ed1074e98b8e..8b9015f081b7 100644 > --- a/arch/x86/kvm/vmx.c > +++ b/arch/x86/kvm/vmx.c > @@ -3662,6 +3662,7 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf) > SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY | > SECONDARY_EXEC_SHADOW_VMCS | > SECONDARY_EXEC_XSAVES | > + SECONDARY_EXEC_RDSEED_EXITING | > SECONDARY_EXEC_ENABLE_PML | > SECONDARY_EXEC_TSC_SCALING | > SECONDARY_EXEC_ENABLE_VMFUNC; > @@ -5298,6 +5299,9 @@ static u32 vmx_secondary_exec_control(struct vcpu_vmx *vmx) > if (!enable_pml) > exec_control &= ~SECONDARY_EXEC_ENABLE_PML; > > + if (guest_cpuid_has(&vmx->vcpu, X86_FEATURE_RDSEED)) > + exec_control &= ~SECONDARY_EXEC_RDSEED_EXITING; > + > return exec_control; > } > > @@ -6806,6 +6810,12 @@ static int handle_mwait(struct kvm_vcpu *vcpu) > return handle_nop(vcpu); > } > > +static int handle_invalid_op(struct kvm_vcpu *vcpu) > +{ > + kvm_queue_exception(vcpu, UD_VECTOR); > + return 1; > +} > + (unrelated to this patch) just wondering if we should now replace most code fragments kvm_queue_exception(vcpu, UD_VECTOR); return 1; by return handle_invalid_op(vcpu); > static int handle_monitor_trap(struct kvm_vcpu *vcpu) > { > return 1; > @@ -8050,6 +8060,7 @@ static int (*const kvm_vmx_exit_handlers[])(struct kvm_vcpu *vcpu) = { > [EXIT_REASON_MONITOR_INSTRUCTION] = handle_monitor, > [EXIT_REASON_INVEPT] = handle_invept, > [EXIT_REASON_INVVPID] = handle_invvpid, > + [EXIT_REASON_RDSEED] = handle_invalid_op, > [EXIT_REASON_XSAVES] = handle_xsaves, > [EXIT_REASON_XRSTORS] = handle_xrstors, > [EXIT_REASON_PML_FULL] = handle_pml_full, > -- Thanks, David