Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp2412320imw; Wed, 6 Jul 2022 05:37:21 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uLYlbcy2S1QKIuRcurwxW6PTLa05wL0u3yecqGxt4cWqwAVIK5GZmDwGKCDSsMZaq5q5XN X-Received: by 2002:a17:90b:1c12:b0:1ef:9067:ed4a with SMTP id oc18-20020a17090b1c1200b001ef9067ed4amr15458508pjb.90.1657111041283; Wed, 06 Jul 2022 05:37:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657111041; cv=none; d=google.com; s=arc-20160816; b=nEsFpyp4y6HscTYgjqEW1y6oVkLEwk8fO4JzB3CyFkewjxUxEBG1mfZdDvF9yeSnom tyJAyLoga6F+hxg1iY/I0itKX6ii8sTS+0kNBIwjdD/ViKTx2fvOeYmo4kHAwf+z4ucV Lr8OxLtxL73APWCFU+AICPpn6plriAJieXTGSOAsD1YGVPJSilgC09d2MhzqlOmYm6p7 24wmXri2l7Tk8mIw5DIqHB5Osb40STCwLl6G9E7Ifm+GwE+B0huTj/0iOQbbTJY9b3Ty /cXFtTtf2SWgUI5M1xS2xueASz8Bl3O9qTu7EjLEsMUNHkn6JE/lM8P/+Q+dNvZ5b+Af w2bQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=RG6ddZS0ZUevI491C3hXszWOwMlAIAahGi08ot1UyoQ=; b=pDPOeHWtWar0N7ZFh0znLaRIBYmvP6k1mjCbFTuXNOIseAUhQN2sCdjz5nt+uUJBS4 5rP3gYhG2yBMG3rZXGs0mdxVcwHrXTTuoWqgi/NUvNGW/tJPJeqZvTXfMODh47eIZbeP e6i/RACsYBveMtdR9LPm+XQiXRd0oNUHz/eHas1Vz3yNWQT9sLHgGEd+T5lrtGQQG/jW K7iSYzpqPNjBhWq7g/j5j0NawBEazIHLCWTm8mARxuAYjmOPpWU6pvdzyzsrSDslTUmc xphnUPO3x9OTaHMG0CJFlI2p0imRqLwpKUD0qmu/bkH7Gx1Ls5sM0AJjzYCMM761IuNl /gUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=I9jCf6M4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z16-20020a056a00241000b005285c2a2e46si14960784pfh.338.2022.07.06.05.37.08; Wed, 06 Jul 2022 05:37:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=I9jCf6M4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232681AbiGFLnQ (ORCPT + 99 others); Wed, 6 Jul 2022 07:43:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232524AbiGFLnO (ORCPT ); Wed, 6 Jul 2022 07:43:14 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AD89C27CE0 for ; Wed, 6 Jul 2022 04:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657107792; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RG6ddZS0ZUevI491C3hXszWOwMlAIAahGi08ot1UyoQ=; b=I9jCf6M4BFfgwFO0hXdyB1sgqEsg9gMunj1nDJrLG8ItARRaIFqyIoY0J/PpUKCHixHdov bMCCEUuaNwSSg03dX1Lr5BR+z/DPVPlTtMRroh/CsMHdij47WLyVC+mtnyIiy/e5r//hFD Si2FCC1AtBZsaClcSP1V7TItraBVt0M= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-329-GNmOByy2MDSnXrZ5vZD9yA-1; Wed, 06 Jul 2022 07:43:09 -0400 X-MC-Unique: GNmOByy2MDSnXrZ5vZD9yA-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4C71B299E74E; Wed, 6 Jul 2022 11:43:09 +0000 (UTC) Received: from starship (unknown [10.40.194.38]) by smtp.corp.redhat.com (Postfix) with ESMTP id EF2B540315A; Wed, 6 Jul 2022 11:43:06 +0000 (UTC) Message-ID: Subject: Re: [PATCH v2 02/21] KVM: VMX: Drop bits 31:16 when shoving exception error code into VMCS From: Maxim Levitsky To: Sean Christopherson , Paolo Bonzini Cc: Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Oliver Upton , Peter Shier Date: Wed, 06 Jul 2022 14:43:05 +0300 In-Reply-To: <20220614204730.3359543-3-seanjc@google.com> References: <20220614204730.3359543-1-seanjc@google.com> <20220614204730.3359543-3-seanjc@google.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2022-06-14 at 20:47 +0000, Sean Christopherson wrote: > Deliberately truncate the exception error code when shoving it into the > VMCS (VM-Entry field for vmcs01 and vmcs02, VM-Exit field for vmcs12). > Intel CPUs are incapable of handling 32-bit error codes and will never > generate an error code with bits 31:16, but userspace can provide an > arbitrary error code via KVM_SET_VCPU_EVENTS. Failure to drop the bits > on exception injection results in failed VM-Entry, as VMX disallows > setting bits 31:16. Setting the bits on VM-Exit would at best confuse > L1, and at worse induce a nested VM-Entry failure, e.g. if L1 decided to > reinject the exception back into L2. Wouldn't it be better to fail KVM_SET_VCPU_EVENTS instead if it tries to set error code with uppper 16 bits set? Or if that is considered ABI breakage, then KVM_SET_VCPU_EVENTS code can truncate the user given value to 16 bit. Best regards, Maxim Levitsky > > Cc: stable@vger.kernel.org > Signed-off-by: Sean Christopherson > --- > arch/x86/kvm/vmx/nested.c | 9 ++++++++- > arch/x86/kvm/vmx/vmx.c | 11 ++++++++++- > 2 files changed, 18 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c > index ee6f27dffdba..33ffc8bcf9cd 100644 > --- a/arch/x86/kvm/vmx/nested.c > +++ b/arch/x86/kvm/vmx/nested.c > @@ -3833,7 +3833,14 @@ static void nested_vmx_inject_exception_vmexit(struct kvm_vcpu *vcpu, > u32 intr_info = nr | INTR_INFO_VALID_MASK; > > if (vcpu->arch.exception.has_error_code) { > - vmcs12->vm_exit_intr_error_code = vcpu->arch.exception.error_code; > + /* > + * Intel CPUs will never generate an error code with bits 31:16 > + * set, and more importantly VMX disallows setting bits 31:16 > + * in the injected error code for VM-Entry. Drop the bits to > + * mimic hardware and avoid inducing failure on nested VM-Entry > + * if L1 chooses to inject the exception back to L2. > + */ > + vmcs12->vm_exit_intr_error_code = (u16)vcpu->arch.exception.error_code; > intr_info |= INTR_INFO_DELIVER_CODE_MASK; > } > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index 5e14e4c40007..ec98992024e2 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -1621,7 +1621,16 @@ static void vmx_queue_exception(struct kvm_vcpu *vcpu) > kvm_deliver_exception_payload(vcpu); > > if (has_error_code) { > - vmcs_write32(VM_ENTRY_EXCEPTION_ERROR_CODE, error_code); > + /* > + * Despite the error code being architecturally defined as 32 > + * bits, and the VMCS field being 32 bits, Intel CPUs and thus > + * VMX don't actually supporting setting bits 31:16. Hardware > + * will (should) never provide a bogus error code, but KVM's > + * ABI lets userspace shove in arbitrary 32-bit values. Drop > + * the upper bits to avoid VM-Fail, losing information that > + * does't really exist is preferable to killing the VM. > + */ > + vmcs_write32(VM_ENTRY_EXCEPTION_ERROR_CODE, (u16)error_code); > intr_info |= INTR_INFO_DELIVER_CODE_MASK; > } >