From patchwork Thu Oct 20 09:30:51 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxim Levitsky X-Patchwork-Id: 412 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4f06:0:0:0:0:0 with SMTP id c6csp175769wru; Thu, 20 Oct 2022 02:39:08 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6xrQTJ8JWsbyNFLZxkjTYwul8TikIVmAMkIqrrtk05ue2/uZMwsXz1pJEps9B0SwUj/QdT X-Received: by 2002:a17:902:b589:b0:179:f8c5:7212 with SMTP id a9-20020a170902b58900b00179f8c57212mr13020773pls.174.1666258748190; Thu, 20 Oct 2022 02:39:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666258748; cv=none; d=google.com; s=arc-20160816; b=B26TkgFfyM4FNuHAWENfSUErkOijgEBJyGJXYrjhyl3yh2YlF1MRkmn6o89z7T9BFN 0PMSOiq4iBPPLUXccJvu3mJi2IwsfSDnzZXjCdXYimXO09aYVU8hcrSoTA6vJkyDT6iJ z9W3INRTbgTIeKmYBQS+zZSMEZ6mnxfZNM8yI0QLt6OWTN6BfhmjVJ04X9QvzgpgaVWb wEe/UZGDi6eFEag6fljJTd+U8Ws76fnOo0iiuC/5zEpAqV4gAkVSa3Qyy/y+MInNDGoM WIsRQFf49WfAugEfa9JVXNCcoemqayLL2IljPAxGMN6cRblNCpk+7DdthEO2oPQ+GZpr ux6w== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=HREmpKeE6zG7wXYYBoUdQLZW+Or4137GWbBcA8ju1B4=; b=djRJ3kCb0c1joDVnNW0IHLnYyNAxa229aW/7D3EDfmTR0XDzNe2D/1Rj3S+qTvVdWx jvrrEkTCxnfRriRmgFzvKsiAaL81blccDyq9fu4HbbM/13VPcUpTgg7v0Qugn5bQDwL/ dznlOR9oSfvC/MOx2605KUgt4n7+uNaMpwWzmj3Jatipv44M098adbXmUIyRjxqgvG4I 2IjY76SFeAf2ARO0gJSPxEqSNXvEkVbqKMr1JcuB+l0Cgm9CJ9htTnpvPiMURAckn790 IgT+b71Zd41dD7WFsS4wVtZwr/exV6GpDfg1BG2WIw91TCd7VlTmuNk2r5y+o+ONeiXi fbGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cHTYczoK; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g26-20020a63111a000000b0042be4a45941si18818095pgl.518.2022.10.20.02.38.54; Thu, 20 Oct 2022 02:39:08 -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=cHTYczoK; 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 S230347AbiJTJbT (ORCPT + 99 others); Thu, 20 Oct 2022 05:31:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230303AbiJTJbQ (ORCPT ); Thu, 20 Oct 2022 05:31:16 -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 ESMTPS id D36F6155DB2 for ; Thu, 20 Oct 2022 02:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666258270; 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; bh=HREmpKeE6zG7wXYYBoUdQLZW+Or4137GWbBcA8ju1B4=; b=cHTYczoKIFbQwJkWGRqtXeYeGRfH1bA+KFDU8K65cl6O1Tu0HyzuvDQrOf4Ul/zcjRGGnR 6M0b0CEipOQGnmbM8EB+CAIYqvhyj6gq0dYAXJQvBjTZvGC5J9n31uBLAhYc1ghRwaO+8h PnQYN7HHF4Gqk94EeQ5hG9f9xD/Bpu4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-653-posLbKhRPH6OIOo4sHzkZw-1; Thu, 20 Oct 2022 05:31:05 -0400 X-MC-Unique: posLbKhRPH6OIOo4sHzkZw-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A02CD882820; Thu, 20 Oct 2022 09:31:04 +0000 (UTC) Received: from localhost.localdomain (ovpn-192-51.brq.redhat.com [10.40.192.51]) by smtp.corp.redhat.com (Postfix) with ESMTP id 75D0E49BB60; Thu, 20 Oct 2022 09:31:01 +0000 (UTC) From: Maxim Levitsky To: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Paolo Bonzini , Borislav Petkov , Ingo Molnar , Sean Christopherson , x86@kernel.org, Thomas Gleixner , Dave Hansen , "H. Peter Anvin" , Maxim Levitsky Subject: [PATCH 0/4] nSVM: fix L0 crash if L2 has shutdown condtion which L1 doesn't intercept Date: Thu, 20 Oct 2022 12:30:51 +0300 Message-Id: <20221020093055.224317-1-mlevitsk@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747198933152815625?= X-GMAIL-MSGID: =?utf-8?q?1747198933152815625?= Recently while trying to fix some unit tests I found another CVE in SVM nested code. In 'shutdown_interception' vmexit handler we call kvm_vcpu_reset. However if running nested and L1 doesn't intercept shutdown, we will still end up running this function and trigger a bug in it. The bug is that this function resets the 'vcpu->arch.hflags' without properly leaving the nested state, which leaves the vCPU in inconsistent state, which later triggers a kernel panic in SVM code. The same bug can likely be triggered by sending INIT via local apic to a vCPU which runs a nested guest. On VMX we are lucky that the issue can't happen because VMX always intercepts triple faults, thus triple fault in L2 will always be redirected to L1. Plus the 'handle_triple_fault' of VMX doesn't reset the vCPU. INIT IPI can't happen on VMX either because INIT events are masked while in VMX mode. Best regards, Maxim Levitsky Maxim Levitsky (4): KVM: x86: nSVM: leave nested mode on vCPU free KVM: x86: nSVM: harden svm_free_nested against freeing vmcb02 while still in use KVM: x86: add kvm_leave_nested KVM: x86: forcibly leave nested mode on vCPU reset arch/x86/kvm/svm/nested.c | 6 +++--- arch/x86/kvm/svm/svm.c | 1 + arch/x86/kvm/vmx/nested.c | 3 --- arch/x86/kvm/x86.c | 9 ++++++++- 4 files changed, 12 insertions(+), 7 deletions(-) --- 2.26.3