From nobody Mon Feb 9 06:25:50 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0D27EB64DD for ; Sat, 29 Jul 2023 00:49:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237087AbjG2Ato (ORCPT ); Fri, 28 Jul 2023 20:49:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236980AbjG2AtX (ORCPT ); Fri, 28 Jul 2023 20:49:23 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29E364497 for ; Fri, 28 Jul 2023 17:48:44 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id d9443c01a7336-1bbb34b091dso18344065ad.0 for ; Fri, 28 Jul 2023 17:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690591659; x=1691196459; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=Hf66Tg9z6eVGNOq7lITDvOc5Z8kagkKjdF0cIF19+es=; b=zUDVdE4s613ECH4ZKVOZpSs/h2tRe54frXNJRURqJl+8Ioud7FLFpSGd152eUfIe5F xPlxDaq0772s0mVBoDJQk5nL4DAEn1P9/YTIRGqB5ythke/tuxa1B3kUdub1M6GRfARi SWYZuWo87quC1VB4Vf6nzVK80CxCjKJd5jxmW7cFtzuojyVIaQxKGnDaTbkIyqK4wvi7 e6N4JtHwrsCpnvh2Jub/ZvB9cJudmmIjBl8RbquwbYbzqg34fwECoUAQdeP07wsO7TJg EoaamLDm4yNiiCYHJxSmV0FlFoYljDv21lPnWdjd5txWiXVKzQWEDTuos8ytThOSce33 OFNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690591659; x=1691196459; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Hf66Tg9z6eVGNOq7lITDvOc5Z8kagkKjdF0cIF19+es=; b=ldJxUERM2larqhDpMa/09mtfz9X5T2ZzQQrhJ0TR8YXg6VLxFjof6HOTuhBpmN++Gj 6HnkgGMnLdhFNmb92bNEZ+XpKbREvlUv7XFIxuPAI1xitXFd+Yg65Qjchz4eis5naKPF 5+bGvcwtCXJMqz3q0ibhqLkRl6IEy8x7FwQHnuRgyEZ+dB1V0KLcPe2g8athS5ny2CIw cQAasmbCUmwQmMqx5J2sYOj3+4q4GnmnmFiU4Ohy6nq3h1q2egZ32JA7k0Q5472d0ZGd cEWe6ZeSwbDFksp/ym7wXt7GR3appE0Nwa/inwSpnZnd0X7lSJ69oJi+RqOIMh/4bwdF k6HQ== X-Gm-Message-State: ABy/qLaYJ6CFBxQ4Jsa/VN9ql/mOXFO5aBdZKlDNzAVsncqWZnJ9itwo 4t2DFPvqXb3luZby/KyARhgje0v5DEc= X-Google-Smtp-Source: APBJJlFZSuUMKPPrvoE2ynK0duyoGM6nzTda9N0M8pKiwM4XCb33H5djCKpyMcK75B3Q4hg2sCX7qCMfWrE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:d2d2:b0:1b9:e8e5:b0a4 with SMTP id n18-20020a170902d2d200b001b9e8e5b0a4mr11360plc.8.1690591659099; Fri, 28 Jul 2023 17:47:39 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 28 Jul 2023 17:47:18 -0700 In-Reply-To: <20230729004722.1056172-1-seanjc@google.com> Mime-Version: 1.0 References: <20230729004722.1056172-1-seanjc@google.com> X-Mailer: git-send-email 2.41.0.487.g6d72f3e995-goog Message-ID: <20230729004722.1056172-9-seanjc@google.com> Subject: [PATCH v3 08/12] KVM: x86/mmu: Bug the VM if a vCPU ends up in long mode without PAE enabled From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Mingwei Zhang , David Matlack , Jim Mattson Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Promote the ASSERT(), which is quite dead code in KVM, into a KVM_BUG_ON() for KVM's sanity check that CR4.PAE=3D1 if the vCPU is in long mode when performing a walk of guest page tables. The sanity is quite cheap since neither EFER nor CR4.PAE requires a VMREAD, especially relative to the cost of walking the guest page tables. More importantly, the sanity check would have prevented the true badness fixed by commit 112e66017bff ("KVM: nVMX: add missing consistency checks for CR0 and CR4"). The missed consistency check resulted in some versions of KVM corrupting the on-stack guest_walker structure due to KVM thinking there are 4/5 levels of page tables, but wiring up the MMU hooks to point at the paging32 implementation, which only allocates space for two levels of page tables in "struct guest_walker32". Queue a page fault for injection if the assertion fails, as both callers, FNAME(gva_to_gpa) and FNAME(walk_addr_generic), assume that walker.fault contains sane info on a walk failure. E.g. not populating the fault info could result in KVM consuming and/or exposing uninitialized stack data before the vCPU is kicked out to userspace, which doesn't happen until KVM checks for KVM_REQ_VM_DEAD on the next enter. Move the check below the initialization of "pte_access" so that the aforementioned to-be-injected page fault doesn't consume uninitialized stack data. The information _shouldn't_ reach the guest or userspace, but there's zero downside to being paranoid in this case. Signed-off-by: Sean Christopherson --- arch/x86/kvm/mmu/paging_tmpl.h | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h index a3fc7c1a7f8d..f8d358226ac6 100644 --- a/arch/x86/kvm/mmu/paging_tmpl.h +++ b/arch/x86/kvm/mmu/paging_tmpl.h @@ -338,7 +338,6 @@ static int FNAME(walk_addr_generic)(struct guest_walker= *walker, } #endif walker->max_level =3D walker->level; - ASSERT(!(is_long_mode(vcpu) && !is_pae(vcpu))); =20 /* * FIXME: on Intel processors, loads of the PDPTE registers for PAE paging @@ -348,6 +347,17 @@ static int FNAME(walk_addr_generic)(struct guest_walke= r *walker, nested_access =3D (have_ad ? PFERR_WRITE_MASK : 0) | PFERR_USER_MASK; =20 pte_access =3D ~0; + + /* + * Queue a page fault for injection if this assertion fails, as callers + * assume that walker.fault contains sane info on a walk failure. I.e. + * avoid making the situation worse by inducing even worse badness + * between when the assertion fails and when KVM kicks the vCPU out to + * userspace (because the VM is bugged). + */ + if (KVM_BUG_ON(is_long_mode(vcpu) && !is_pae(vcpu), vcpu->kvm)) + goto error; + ++walker->level; =20 do { --=20 2.41.0.487.g6d72f3e995-goog