Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2468137yba; Mon, 15 Apr 2019 12:16:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqyObCeQMg5WXGVIMAHUxXITRxapYGIgGxFf9i3zwPHMlvkmvmG1zVwD8K/DLRdpaxeYPlXv X-Received: by 2002:a17:902:bb84:: with SMTP id m4mr37890494pls.302.1555355763628; Mon, 15 Apr 2019 12:16:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555355763; cv=none; d=google.com; s=arc-20160816; b=fQENoOsY0KugWAogHjvL3rgcJj/hvglJjMpax6VipgElFjid1fjOilw3BM5qO023Gx MbOUyuid/F0mOKCoYE+CUSOk+ZhfkxsanV9EF7t6P7ZDvNzLw5u4dLSp6vOI2BRk4FcF vYnVTgFPiBrqs+wDpNJRnivETEOhbxZjepmlP+Dl4O0AZZd1PRMDDYd6Xx0zCtBJPUaJ 7gkcrYhF3qCZDSQIWdNQb+oBxi8DhWTvc6ObwEcHRmzHMwWGWL/jVNPWPeehkjWp2RTs FhsWaVuQDE+D18VvoWJ7Nh6DlXwGhAX2SYe2BFMAd2GKnfxpnRDVNCS6uGsFEdZaTKOM kjNQ== 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:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=HdJDWKDUSRrGUd8QB4i9w48+Q43qWk7r0487VrIjGwU=; b=jg2r0IIGECy2TJeH5CF/S+ScSWLpeYUNcLazysKgn1pvGqN8t0VwaZOwVzj6AA62jM x9H4UGUy2s+IOiFSAvv2JdUqXq38RViVh8rUgYiY2UafqTTpjn9yn+CTZ5Y9tTWOucXh aeOVal3p8MtMMJ57jEvoSbxQxJOT5FPoD8PIwEWNAS5lT03iuz5CGoMm3SRsTvIPBQmy qxe5zbqO5dFgSVnnIGZehPGrli0rdIdOg/b2uD+SoUHMYbgTGBfzY5h+RO6jpbGnlwAb k99k4Ji7QPG89Daj10oEa0q385Ywl1gA5w1Peov0cX6zlMNo9r8/3UlWXSpFwBNXMPGn M7ww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=JSFi0JNQ; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k19si48072466pfb.139.2019.04.15.12.15.47; Mon, 15 Apr 2019 12:16:03 -0700 (PDT) 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=@kernel.org header.s=default header.b=JSFi0JNQ; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731000AbfDOTOd (ORCPT + 99 others); Mon, 15 Apr 2019 15:14:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:52708 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731761AbfDOTOa (ORCPT ); Mon, 15 Apr 2019 15:14:30 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0449E218A1; Mon, 15 Apr 2019 19:14:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555355669; bh=gaBmqIDeN6ywm83XEAwRBmVKngKeB9uRIsQJaHtpDNM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JSFi0JNQHV6hxIpIFF0c916GiMSKp4WIY8iaYFDvCPnbsI9/lbHxXMrxGE5GR8KGf XmupZ4CygwEqqSHVjRQGKoiaCCroVxWHC5CrV8n52Azs0PlLdaqDf2IxjoAKXyhVxJ q64Mi8EVw/ReyrJ0Sa03XR/fcUy1nOZobzWGGq7M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marc Orr , Jim Mattson , Paolo Bonzini Subject: [PATCH 5.0 115/117] KVM: x86: nVMX: close leak of L0s x2APIC MSRs (CVE-2019-3887) Date: Mon, 15 Apr 2019 21:01:25 +0200 Message-Id: <20190415183750.601949838@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190415183744.887851196@linuxfoundation.org> References: <20190415183744.887851196@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Marc Orr commit acff78477b9b4f26ecdf65733a4ed77fe837e9dc upstream. The nested_vmx_prepare_msr_bitmap() function doesn't directly guard the x2APIC MSR intercepts with the "virtualize x2APIC mode" MSR. As a result, we discovered the potential for a buggy or malicious L1 to get access to L0's x2APIC MSRs, via an L2, as follows. 1. L1 executes WRMSR(IA32_SPEC_CTRL, 1). This causes the spec_ctrl variable, in nested_vmx_prepare_msr_bitmap() to become true. 2. L1 disables "virtualize x2APIC mode" in VMCS12. 3. L1 enables "APIC-register virtualization" in VMCS12. Now, KVM will set VMCS02's x2APIC MSR intercepts from VMCS12, and then set "virtualize x2APIC mode" to 0 in VMCS02. Oops. This patch closes the leak by explicitly guarding VMCS02's x2APIC MSR intercepts with VMCS12's "virtualize x2APIC mode" control. The scenario outlined above and fix prescribed here, were verified with a related patch in kvm-unit-tests titled "Add leak scenario to virt_x2apic_mode_test". Note, it looks like this issue may have been introduced inadvertently during a merge---see 15303ba5d1cd. Signed-off-by: Marc Orr Reviewed-by: Jim Mattson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman --- arch/x86/kvm/vmx/nested.c | 72 ++++++++++++++++++++++++++++------------------ 1 file changed, 44 insertions(+), 28 deletions(-) --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -500,6 +500,17 @@ static void nested_vmx_disable_intercept } } +static inline void enable_x2apic_msr_intercepts(unsigned long *msr_bitmap) { + int msr; + + for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) { + unsigned word = msr / BITS_PER_LONG; + + msr_bitmap[word] = ~0; + msr_bitmap[word + (0x800 / sizeof(long))] = ~0; + } +} + /* * Merge L0's and L1's MSR bitmap, return false to indicate that * we do not use the hardware. @@ -541,39 +552,44 @@ static inline bool nested_vmx_prepare_ms return false; msr_bitmap_l1 = (unsigned long *)kmap(page); - if (nested_cpu_has_apic_reg_virt(vmcs12)) { - /* - * L0 need not intercept reads for MSRs between 0x800 and 0x8ff, it - * just lets the processor take the value from the virtual-APIC page; - * take those 256 bits directly from the L1 bitmap. - */ - for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) { - unsigned word = msr / BITS_PER_LONG; - msr_bitmap_l0[word] = msr_bitmap_l1[word]; - msr_bitmap_l0[word + (0x800 / sizeof(long))] = ~0; - } - } else { - for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) { - unsigned word = msr / BITS_PER_LONG; - msr_bitmap_l0[word] = ~0; - msr_bitmap_l0[word + (0x800 / sizeof(long))] = ~0; - } - } - nested_vmx_disable_intercept_for_msr( - msr_bitmap_l1, msr_bitmap_l0, - X2APIC_MSR(APIC_TASKPRI), - MSR_TYPE_W); + /* + * To keep the control flow simple, pay eight 8-byte writes (sixteen + * 4-byte writes on 32-bit systems) up front to enable intercepts for + * the x2APIC MSR range and selectively disable them below. + */ + enable_x2apic_msr_intercepts(msr_bitmap_l0); + + if (nested_cpu_has_virt_x2apic_mode(vmcs12)) { + if (nested_cpu_has_apic_reg_virt(vmcs12)) { + /* + * L0 need not intercept reads for MSRs between 0x800 + * and 0x8ff, it just lets the processor take the value + * from the virtual-APIC page; take those 256 bits + * directly from the L1 bitmap. + */ + for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) { + unsigned word = msr / BITS_PER_LONG; + + msr_bitmap_l0[word] = msr_bitmap_l1[word]; + } + } - if (nested_cpu_has_vid(vmcs12)) { - nested_vmx_disable_intercept_for_msr( - msr_bitmap_l1, msr_bitmap_l0, - X2APIC_MSR(APIC_EOI), - MSR_TYPE_W); nested_vmx_disable_intercept_for_msr( msr_bitmap_l1, msr_bitmap_l0, - X2APIC_MSR(APIC_SELF_IPI), + X2APIC_MSR(APIC_TASKPRI), MSR_TYPE_W); + + if (nested_cpu_has_vid(vmcs12)) { + nested_vmx_disable_intercept_for_msr( + msr_bitmap_l1, msr_bitmap_l0, + X2APIC_MSR(APIC_EOI), + MSR_TYPE_W); + nested_vmx_disable_intercept_for_msr( + msr_bitmap_l1, msr_bitmap_l0, + X2APIC_MSR(APIC_SELF_IPI), + MSR_TYPE_W); + } } if (spec_ctrl)