Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp3086379rwb; Mon, 15 Aug 2022 17:47:50 -0700 (PDT) X-Google-Smtp-Source: AA6agR7f11BHR4AhkAROD9JZwDkEVvmDG+CX57q8odFZDTqvVAqX6e113ZgQOo7UCOYaaByPra2K X-Received: by 2002:a05:6402:b6a:b0:43d:2454:ddd3 with SMTP id cb10-20020a0564020b6a00b0043d2454ddd3mr16633786edb.138.1660610870579; Mon, 15 Aug 2022 17:47:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660610870; cv=none; d=google.com; s=arc-20160816; b=xbGP0AaSV7UEFU/Nu/J5iDy4lCGfR/w0ToV0p/3ZtBtqBIUjIDcTtaytaZj+0UcNV7 qz5fCv8k9DItEb0DaOucqDJa/KNQJSnedjKIp48dvBO96OJjL+XEJBjVjqry0ETQWKPA mzXNVHUB7DJCVvNFHMLBim8L+I+92kwb8/EDcA4Qv4FCH6ZA9N4iyNdN5ACF/DOJtaI1 vjUogWhn+6mLFQsFk18q6YFNaVC6Py7BOwCNIUeAg66c09FyLv2RI1ai/2pJgBo6j00b q/ig+1F2U85X7ectMuu/ohPawBPaBaKsCHUsltoVe3/ZrA2HaexFtgH+rw4NsombRlrj FbRw== 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:message-id:date:subject:cc:to :from:dkim-signature; bh=Pr7zzU4DWHY2Tp4CvU18GaSF5ev3UTliXaXvVYHPsN0=; b=lvxVxoFohHfmnhl+UVtF5gbusdEhJp5rewfZ7E29JCt/KxfCHkqlHN2AHl+rdrb2a5 bkXCCfnPU0IcmKrVZq9w0c2v6oy25wkU5eskjQNbZBjnKO70DztlJ8G4FRJxrV1yztPa TTbDkD/tFuMc+f9GwOL9CKw/ARjw2awsbvN6K1DwE5+t5tTYJ+ByJTycN638FamStTr3 cECp82mbQkuGMM0L3HmiEbMF6efd9FGPTbL4me41r8xsnesPuc0JB8xeMl7FXRu/qgFB E+qhSsyAec+qXvUKHGjdTt4kDV88oAO/d+5C6+zYGdLYF5ryGPDfofDT3Y/3sLN6ir0H ipBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=FtkumCos; 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=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b8-20020a056402084800b0043defd3ed96si10972243edz.237.2022.08.15.17.47.25; Mon, 15 Aug 2022 17:47:50 -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=@linuxfoundation.org header.s=korg header.b=FtkumCos; 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=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348909AbiHPAKZ (ORCPT + 99 others); Mon, 15 Aug 2022 20:10:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46328 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355872AbiHPABn (ORCPT ); Mon, 15 Aug 2022 20:01:43 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3ADB1166D27; Mon, 15 Aug 2022 13:23:11 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AEF21B81197; Mon, 15 Aug 2022 20:23:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 091C6C433D6; Mon, 15 Aug 2022 20:23:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660594988; bh=T0ExjDB8KA/b2kObAeatt24PNH44YeP1h8h5PP27O2g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FtkumCosk81wcjHONdgiOvnC6AuI1yJ8mn6HHO20btYv8YnnQRTTqvlnL8vMIMlA7 EvEViw7ZBeQh8nocS5MLXieS7zIqieRQx/z11lpFaaTJyqQIdG1w+Vgt6Ttm6r2jR8 Zu5oq37bM6Q6T0bb/1gq5cBw1HXARkd2/EaLcRp0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maxim Levitsky , Sean Christopherson , "Maciej S. Szmigiero" , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.19 0590/1157] KVM: SVM: Unwind "speculative" RIP advancement if INTn injection "fails" Date: Mon, 15 Aug 2022 19:59:06 +0200 Message-Id: <20220815180503.256234961@linuxfoundation.org> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20220815180439.416659447@linuxfoundation.org> References: <20220815180439.416659447@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 From: Sean Christopherson [ Upstream commit cd9e6da8048c5b40315ee2d929b6230ce1252c3c ] Unwind the RIP advancement done by svm_queue_exception() when injecting an INT3 ultimately "fails" due to the CPU encountering a VM-Exit while vectoring the injected event, even if the exception reported by the CPU isn't the same event that was injected. If vectoring INT3 encounters an exception, e.g. #NP, and vectoring the #NP encounters an intercepted exception, e.g. #PF when KVM is using shadow paging, then the #NP will be reported as the event that was in-progress. Note, this is still imperfect, as it will get a false positive if the INT3 is cleanly injected, no VM-Exit occurs before the IRET from the INT3 handler in the guest, the instruction following the INT3 generates an exception (directly or indirectly), _and_ vectoring that exception encounters an exception that is intercepted by KVM. The false positives could theoretically be solved by further analyzing the vectoring event, e.g. by comparing the error code against the expected error code were an exception to occur when vectoring the original injected exception, but SVM without NRIPS is a complete disaster, trying to make it 100% correct is a waste of time. Reviewed-by: Maxim Levitsky Fixes: 66b7138f9136 ("KVM: SVM: Emulate nRIP feature when reinjecting INT3") Signed-off-by: Sean Christopherson Signed-off-by: Maciej S. Szmigiero Message-Id: <450133cf0a026cb9825a2ff55d02cb136a1cb111.1651440202.git.maciej.szmigiero@oracle.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin --- arch/x86/kvm/svm/svm.c | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 40e560c875f1..fe8536c57fd7 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -3699,6 +3699,18 @@ static void svm_complete_interrupts(struct kvm_vcpu *vcpu) vector = exitintinfo & SVM_EXITINTINFO_VEC_MASK; type = exitintinfo & SVM_EXITINTINFO_TYPE_MASK; + /* + * If NextRIP isn't enabled, KVM must manually advance RIP prior to + * injecting the soft exception/interrupt. That advancement needs to + * be unwound if vectoring didn't complete. Note, the _new_ event may + * not be the injected event, e.g. if KVM injected an INTn, the INTn + * hit a #NP in the guest, and the #NP encountered a #PF, the #NP will + * be the reported vectored event, but RIP still needs to be unwound. + */ + if (int3_injected && type == SVM_EXITINTINFO_TYPE_EXEPT && + kvm_is_linear_rip(vcpu, svm->int3_rip)) + kvm_rip_write(vcpu, kvm_rip_read(vcpu) - int3_injected); + switch (type) { case SVM_EXITINTINFO_TYPE_NMI: vcpu->arch.nmi_injected = true; @@ -3712,16 +3724,11 @@ static void svm_complete_interrupts(struct kvm_vcpu *vcpu) /* * In case of software exceptions, do not reinject the vector, - * but re-execute the instruction instead. Rewind RIP first - * if we emulated INT3 before. + * but re-execute the instruction instead. */ - if (kvm_exception_is_soft(vector)) { - if (vector == BP_VECTOR && int3_injected && - kvm_is_linear_rip(vcpu, svm->int3_rip)) - kvm_rip_write(vcpu, - kvm_rip_read(vcpu) - int3_injected); + if (kvm_exception_is_soft(vector)) break; - } + if (exitintinfo & SVM_EXITINTINFO_VALID_ERR) { u32 err = svm->vmcb->control.exit_int_info_err; kvm_requeue_exception_e(vcpu, vector, err); -- 2.35.1