Received: by 10.223.164.202 with SMTP id h10csp6255074wrb; Wed, 22 Nov 2017 01:32:40 -0800 (PST) X-Google-Smtp-Source: AGs4zMYz3XYMwBGOg6Hv0WaVMOq10ckgvslTQn4oxnTrlrS2w0COxFq6aapGAmPmsZtBru3mjJKW X-Received: by 10.159.229.136 with SMTP id az8mr20737942plb.423.1511343160509; Wed, 22 Nov 2017 01:32:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511343160; cv=none; d=google.com; s=arc-20160816; b=ccp9/sTMLpI7u9eBmS24GPGgdP3w5WScAG9oppEy4E0DCniiEgWFMhOQsrJKDwOGET ICVihPSYvwCD8uAF71dobAbM58+PoB/vzSw9gz26S4YVXO0mBRxD/XYzrrE8rE0//s1V Riu17nbi6D6nKjIKRuy2/5Vbq5PWalLxkfOyLowgQP9DaNd5DQvrFa31rULKRWaCmLBe XVyXgfJfLjF3cZyRIPjOwcH4UcyvluMMZs2Ep/vz7Gmbao5jFpN3guH+rSDd/XwOSnNi H5ZxDUAvoeBv42zrD/LZ/6nZrOTKVcDiMWE2WbISeWLxV9/dDCcZBBvyWZMR+RF681Oq pIqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=h9FKE9DOZ8WVUUkVmQV+3OBsWKwWGMQk8uL9NXPjgas=; b=oSLvoiO7yLBSHfZAkZwjYXo6LaYY7v+5D6Voorfpf48UasIw6NYy6w1kSDo7KJkx+6 yEW1LIHJDiIErxT515tQTLkzUrpI0waOvLGXTMkJOwF+BOPJMyTr2E6q02m8IzRxq9Cd 14/lifARpszOnSAordflk0LQ4EqG/oT20ddnQRB1pAOEV+e855GAE3nNV9SeV3LX6vLW 60E1ukRbh7Fo7scCFbBWNZptr6362zhBKCGp76SI9BKtbMs2NogBH2YWQM/NGQPy9udd OKHVddSuJuKDqikT7mv/4tFHWk3XCmlKCM0JcAkoUJHvJuXC7maETaq278m6ibFSdYpP NNcw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=M4hTsicN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 78si11254766pfq.361.2017.11.22.01.32.29; Wed, 22 Nov 2017 01:32:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=M4hTsicN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751734AbdKVJbv (ORCPT + 75 others); Wed, 22 Nov 2017 04:31:51 -0500 Received: from mail-oi0-f67.google.com ([209.85.218.67]:40751 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751273AbdKVJbs (ORCPT ); Wed, 22 Nov 2017 04:31:48 -0500 Received: by mail-oi0-f67.google.com with SMTP id l138so10505073oib.7; Wed, 22 Nov 2017 01:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=h9FKE9DOZ8WVUUkVmQV+3OBsWKwWGMQk8uL9NXPjgas=; b=M4hTsicNa0m59Xk8UoKPN3BsZpYNhLoXkxcDR97qTy311tfbq60ZEjFg/nXn3OsB8s 0mFN3UfL5D+wg06yB1CbFznvHpz3LUW6hAUYLIX3BLlU/QkueGOuS/Cy+acegdrxtSve zBy7Tlfqs0wukg8H9kLFR+m9rbp6sJYan8zGQOe8Ueo0QeE38yu51Oi8QBouwgHYDvNQ OP4GZS1NknC9cDdyVllbHuFFN0jiYR3OcYiMdDnXznNsay14uqcBzpvRKjkE0miC1Pn3 U4cSrgceSR9J6lnO2HvbY2A8yTTPSNIBLk4tAm2PXRgoBXYx66+rbf6p99Y1Mj7ptlMG ZHjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=h9FKE9DOZ8WVUUkVmQV+3OBsWKwWGMQk8uL9NXPjgas=; b=ELo+/d/XinLTi1rKb6ViNAB6PAbOWboRrex9txX8v2N4Qm8/y30mNihFcpy2GMfy+N 3fQ01lpD8ajIEXl92ez7+5CXO20p0SwiKUCLYDevH2BNq7sQ0XPzOgFDFiAUpyS0pUjm VoXHIm9aGyDoSAE9Wj8tyuWnhBpeAeYSRQaTqXFaXisjq+GtnrbBddkYmRM9ooeFOOwR CQVdcGVJRza5VuqTEeq3X5L4jTS8ty5LRQa1nJfxyIQyEBJgxBlNOwM5p/OsHcHXGiEj E18v2Qpc/cHH4Iu+RUJsh2JjS86bFBd264f6qT23Ec782WhT4/hSNTLHZTd8IfpU/8OI G3bw== X-Gm-Message-State: AJaThX47Qa6eOKH3ZW7D+W/F95Q2gxsTJVok9tr8H8X6CU9LUyWzYeGU Feu9HxdlJfarerj80NIYOgvKNPHZ+qiV1x+Dfz0= X-Received: by 10.202.10.70 with SMTP id 67mr11570751oik.271.1511343107288; Wed, 22 Nov 2017 01:31:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.182.67 with HTTP; Wed, 22 Nov 2017 01:31:46 -0800 (PST) In-Reply-To: <5A153E5B.2060104@ORACLE.COM> References: <1511337410-8100-1-git-send-email-wanpeng.li@hotmail.com> <5A153926.7030004@ORACLE.COM> <5A153E5B.2060104@ORACLE.COM> From: Wanpeng Li Date: Wed, 22 Nov 2017 17:31:46 +0800 Message-ID: Subject: Re: [PATCH] KVM: VMX: Fix vmx->nested freeing when no SMI handler To: Liran Alon Cc: "linux-kernel@vger.kernel.org" , kvm , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Wanpeng Li , Dmitry Vyukov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-11-22 17:07 GMT+08:00 Liran Alon : > > > On 22/11/17 10:45, Liran Alon wrote: >> >> >> >> On 22/11/17 09:56, Wanpeng Li wrote: >>> >>> From: Wanpeng Li >>> >>> Reported by syzkaller: >>> >>> ------------[ cut here ]------------ >>> WARNING: CPU: 5 PID: 2939 at arch/x86/kvm/vmx.c:3844 >>> free_loaded_vmcs+0x77/0x80 [kvm_intel] >>> CPU: 5 PID: 2939 Comm: repro Not tainted 4.14.0+ #26 >>> RIP: 0010:free_loaded_vmcs+0x77/0x80 [kvm_intel] >>> Call Trace: >>> vmx_free_vcpu+0xda/0x130 [kvm_intel] >>> kvm_arch_destroy_vm+0x192/0x290 [kvm] >>> kvm_put_kvm+0x262/0x560 [kvm] >>> kvm_vm_release+0x2c/0x30 [kvm] >>> __fput+0x190/0x370 >>> task_work_run+0xa1/0xd0 >>> do_exit+0x4d2/0x13e0 >>> do_group_exit+0x89/0x140 >>> get_signal+0x318/0xb80 >>> do_signal+0x8c/0xb40 >>> exit_to_usermode_loop+0xe4/0x140 >>> syscall_return_slowpath+0x206/0x230 >>> entry_SYSCALL_64_fastpath+0x98/0x9a >>> >>> The syzkaller testcase will execute VMXON/VMLAUCH instructions, so the >>> vmx->nested stuff is populated, it will also issue KVM_SMI ioctl. >>> However, >>> the testcase is just a simple c program and not be lauched by something >>> like seabios which implements smi_handler. Commit 05cade71cf (KVM: nSVM= : >>> fix SMI injection in guest mode) gets out of guest mode and set >>> nested.vmxon >>> to false for the duration of SMM according to SDM 34.14.1 "leave VMX >>> operation" upon entering SMM. We can't alloc/free the vmx->nested stuff >>> each time when entering/exiting SMM since it will induce more >>> overhead. So >>> the function vmx_pre_enter_smm() marks nested.vmxon false even if >>> vmx->nested >>> stuff is still populated. What it expected is em_rsm() can mark >>> nested.vmxon >>> to be true again. However, the smi_handler/rsm will not execute since >>> there >>> is no something like seabios in this scenario. The function free_nested= () >>> fails to free the vmx->nested stuff since the vmx->nested.vmxon is fals= e >>> which results in the above warning. >>> >>> This patch fixes it by also considering the no SMI handler case, luckil= y >>> vmx->nested.smm.vmxon is marked according to the value of >>> vmx->nested.vmxon >>> in vmx_pre_enter_smm(), we can take advantage of it and free vmx->neste= d >>> stuff when L1 goes down. >>> >>> Reported-by: Dmitry Vyukov >>> Cc: Paolo Bonzini >>> Cc: Radim Kr=C4=8Dm=C3=A1=C5=99 >>> Cc: Dmitry Vyukov >>> Fixes: 05cade71cf (KVM: nSVM: fix SMI injection in guest mode) >>> Signed-off-by: Wanpeng Li >>> --- >>> arch/x86/kvm/vmx.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >>> index dccc0f7..ed22425 100644 >>> --- a/arch/x86/kvm/vmx.c >>> +++ b/arch/x86/kvm/vmx.c >>> @@ -7372,7 +7372,7 @@ static inline void nested_release_vmcs12(struct >>> vcpu_vmx *vmx) >>> */ >>> static void free_nested(struct vcpu_vmx *vmx) >>> { >>> - if (!vmx->nested.vmxon) >>> + if (!vmx->nested.vmxon && !vmx->nested.smm.vmxon) >>> return; >>> >>> vmx->nested.vmxon =3D false; >>> >> Funny bug. Great analysis. >> Reviewed-by: Liran Alon > > Actually, I would add one more thing to patch: > I think we should also set "vmx->nested.smm.vmxon =3D false;" after > "vmx->nested.vmxon =3D false;" to correctlyhandle the case VMXOFF is exec= uted > from SMI handler. Otherwise, when SMI handler executes RSM, we will reach > vmx_pre_leave_smm() which will set again "vmx->nested.vmxon =3D true;" wh= ich I > think shouldn't happen. I didn't see a real scenario for this. Regards, Wanpeng Li From 1584756754809361477@xxx Wed Nov 22 09:10:14 +0000 2017 X-GM-THRID: 1584752194833300147 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread