Received-SPF: pass (google.com: domain of linux-kernel+bounces-146801-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Julian Stecklina <julian.stecklina@cyberus-technology.de>
To: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Prescher <thomas.prescher@cyberus-technology.de>,
	Julian Stecklina <julian.stecklina@cyberus-technology.de>,
	kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH 1/2] KVM: nVMX: fix CR4_READ_SHADOW when L0 updates CR4 during a signal
Date: Tue, 16 Apr 2024 14:35:56 +0200
Message-ID: <20240416123558.212040-1-julian.stecklina@cyberus-technology.de>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?mUYSpRUs8SNZuhhpPdAO4waLeoDnjYiZ1xTRSDM7fGp2cbyY+akneOaGj80g?=
 =?us-ascii?Q?yqcw6837IcIlkhtwF+iGniJUTQAecVSBTKGwnUiktjH+eZimM0VwhX/FkYTP?=
 =?us-ascii?Q?NMXW2lY375+daOSmAGEISDGCjZlwz08kAYwCrVkuS/Tr7pKfcF7/8xEg/r1h?=
 =?us-ascii?Q?vd2doLzzLjcIUCCraSTGfxBsMqkkr2HRTEPa/bdMBuAQca7QOGUW4CsrY9l+?=
 =?us-ascii?Q?SWqxrIw8HW505kGru2E4N2O+GnH/2jAuLQiUzXA+ZT37HRt9JT9oneCfqpqi?=
 =?us-ascii?Q?aqEdrjVr2bINhPMEFRpxhS1TWgsb30PAlcXXTMdbGOxS+VOCeHw6jsKlXQSq?=
 =?us-ascii?Q?Cid6YlkMDXz2AfCvgvZSBZ5DI0Iz7lZrKEO9fYAGbMxYx1xchBPivfEXdHbX?=
 =?us-ascii?Q?WXspvIrivysdXHllwlKJ+luqv7wM4iPkIxaEmVpKylwlXjlUYBEuC+PmvAQw?=
 =?us-ascii?Q?ggXpma4QO58FN85paGkTOPA/DBBsWZsKww/HDFme70WmlTw2l8ThKVzDjcG8?=
 =?us-ascii?Q?jq9+pv+uK1QzYBl5K14Dop2N+ERN74FOIVm74NnnwkPJz+62X4C3ZUvxAwx1?=
 =?us-ascii?Q?u20rFogiTZiUSvCxxF9j/oxWi7sezzrYpimeJg4EzjwexjOWDAEMSWGVt+oW?=
 =?us-ascii?Q?QX9KRZhSsgItE5zJBCbFlJ7TBpme1kcKkztJmpIMckW5Yco+ZJF3ta/fvqxJ?=
 =?us-ascii?Q?tXoUdH+8LOjp1KHkEOT/wmUYi0H8kapHLHTxzirEc1VNHTvLq/OT0ZCtjaAR?=
 =?us-ascii?Q?2G0hdL4DXm6BvlS7sVZm6e6vycl+vk8YLfUQXTv/WgHm3DKRnWBhsOlPTTKB?=
 =?us-ascii?Q?dOiWDdl2ANhOyvBFN5CLw451HvRVyIJJApp4sLzpfuvnYF3UQcGqNgkPmx9N?=
 =?us-ascii?Q?FZ0F9iC53EcbVAYKMaU7Nl6VEyaLbp9UOXNU9tlupy6eP/PmSV5aEHbyQfdl?=
 =?us-ascii?Q?TBrMOfMtZMKld5fvdUrVxMOgPNHI48Bilz4dlPXRll6k//w56ttnCQ4dZmBR?=
 =?us-ascii?Q?s2VDEgyp3soBsLChLRtBsszqsCf8KFV/9J6LvRYEl/niZde3fnFzc+aIjana?=
 =?us-ascii?Q?0YjjoPT3ki2aMwaYQJFAK8mywZ5Q6/NY2dMcJCrR2/csGaUOeOzeQgcBIin5?=
 =?us-ascii?Q?wlOIH8DPq6F7U0dqaGPFaOqEH2iKGBK4Ko6QhdCxzp+4vkP+z6OrjzMlmrHX?=
 =?us-ascii?Q?qCzWIR3MRw33kbezAeFOZZU3MUF9+ZOQr2gTkiBVHSn+vcbgqF31HadycrDt?=
 =?us-ascii?Q?iS9PWLYPCK/ox5Z4stSg/eUMx3JwwXA7siYZS/3MMtv14oKX27jcHYNgsLXj?=
 =?us-ascii?Q?iiMBQuHKTu7A4SqhL8YZI1XfqmOZInJxu+Xla/WbJSZyEhEXlasS2WkJBpUM?=
 =?us-ascii?Q?ozLXgriE55tiTrLZr58zsdHiKmfXUfFcZUM96xhJKxhRUidKENWp+/UFsY5I?=
 =?us-ascii?Q?/s36TygwDTbnGBWfEWem61nhp8pWVT5EXeLJqTCZEE4N1gH6mSwvgUIVTqVk?=
 =?us-ascii?Q?Qh4ci+euVvJIdfWc83NhNqv8ZHXinHzpIOnbWjqwZpms0edB4BZzn2ZJkdBx?=
 =?us-ascii?Q?8o9eIN8pPD8M0rm+wyoZ+8xXvT7Zl1or8x8FMqXgPhgwvrcnG5Vwcsz+XLaU?=
 =?us-ascii?Q?Szilt6Th9n0CklZ+SpUxHcU=3D?=
X-OriginatorOrg: cyberus-technology.de
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a5f1b05-de4c-4a1e-a355-08dc5e11dc72
X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB2329.DEUP281.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2024 12:36:38.7138
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f4e0f4e0-9d68-4bd6-a95b-0cba36dbac2e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 3Ve3BSVMTG8EUL5E8/sY+Agm/CBL0j4mQ8Kl+N6YSXyWuqbDaNw8t1m+xXwnKU0lN3/QlRKm0vQ0kmf5Rx0hCMYXNChJWj0xmN1CMWF47/vo3RkdvUY7Vt5kxYyk8iGU
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB1543

From: Thomas Prescher <thomas.prescher@cyberus-technology.de>

This issue occurs when the kernel is interrupted by a signal while
running a L2 guest. If the signal is meant to be delivered to the L0
VMM, and L0 updates CR4 for L1, i.e. when the VMM sets
KVM_SYNC_X86_SREGS in kvm_run->kvm_dirty_regs, the kernel programs an
incorrect read shadow value for L2's CR4.

The result is that the guest can read a value for CR4 where bits from
L1 have leaked into L2.

We found this issue by running uXen [1] as L2 in VirtualBox/KVM [2].
The issue can also easily be reproduced in Qemu/KVM if we force a sreg
sync on each call to KVM_RUN [3]. The issue can also be reproduced by
running a L2 Windows 10. In the Windows case, CR4.VMXE leaks from L1
to L2 causing the OS to blue-screen with a kernel thread exception
during TLB invalidation where the following code sequence triggers the
issue:

mov rax, cr4 <--- L2 reads CR4 with contents from L1
mov rcx, cr4
btc 0x7, rax <--- L2 toggles CR4.PGE
mov cr4, rax <--- #GP because L2 writes CR4 with reserved bits set
mov cr4, rcx

The existing code seems to fixup CR4_READ_SHADOW after calling
vmx_set_cr4 except in __set_sregs_common. While we could fix it there
as well, it's easier to just handle it centrally.

There might be a similar issue with CR0.

[1] https://github.com/OpenXT/uxen
[2] https://github.com/cyberus-technology/virtualbox-kvm
[3] https://github.com/tpressure/qemu/commit/d64c9d5e76f3f3b747bea7653d677bd61e13aafe

Signed-off-by: Julian Stecklina <julian.stecklina@cyberus-technology.de>
Signed-off-by: Thomas Prescher <thomas.prescher@cyberus-technology.de>
---
 arch/x86/kvm/vmx/vmx.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 6780313914f8..0d4af00245f3 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -3474,7 +3474,11 @@ void vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
 			hw_cr4 &= ~(X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_PKE);
 	}
 
-	vmcs_writel(CR4_READ_SHADOW, cr4);
+	if (is_guest_mode(vcpu))
+		vmcs_writel(CR4_READ_SHADOW, nested_read_cr4(get_vmcs12(vcpu)));
+	else
+		vmcs_writel(CR4_READ_SHADOW, cr4);
+
 	vmcs_writel(GUEST_CR4, hw_cr4);
 
 	if ((cr4 ^ old_cr4) & (X86_CR4_OSXSAVE | X86_CR4_PKE))
-- 
2.43.2