From nobody Sun Jun 14 17:44:16 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 C7853C433FE for ; Fri, 13 May 2022 19:50:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1383935AbiEMTuL (ORCPT ); Fri, 13 May 2022 15:50:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38202 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1383915AbiEMTuH (ORCPT ); Fri, 13 May 2022 15:50:07 -0400 Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 843622DC6 for ; Fri, 13 May 2022 12:50:05 -0700 (PDT) Received: by mail-pj1-x1049.google.com with SMTP id q3-20020a17090a304300b001dd2130b435so4819857pjl.0 for ; Fri, 13 May 2022 12:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=f7yzhfisk2h8SeZqMk+S4T8cT4lhDdnwCiG3Dpdd8fo=; b=pDK8cgIt+nRNbSGx8CFEQTj3ejYbBQrgiRGoeUNz3MJMNd1xbE9rZnQrT9/55ZuyRU ZXWBpxSXylg+TutIljZ3z4P6vfOS8tHOdWC9H20Rqxni7xPlBMrvE1e3khOO0biZrPMA 6KuRRwULLCi5v3071KvZdVd/ieraSJ5BpCHv8clwiWSXw5BQ1QJTl6WJFEKrnKdna8os zGN+3NPeY4ROds4c5WuGUIXxSxShCDiHwk0TC9FtijtVaE5cPHrpUfvNRsPj83cPMtxE gCSNU9hV5KwLmm+QJmh1ZrBSOKIM9Roc3qXbV9z++ME/AQCBSPiD/0OF/8gw+/7rg2Fn vFXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=f7yzhfisk2h8SeZqMk+S4T8cT4lhDdnwCiG3Dpdd8fo=; b=INrVcSJyXP0GYySqi6QlXmYPemn2wTILBls4ZGxUcvwn325k1RU8V5qOQTTetkoUjq BKKiQnHmO6Nrn9SgVA7yE0Sr9uDmIkoN2TKtwS8NRxKe9DCwuR5DN810NIIcFNhe9TBu NR9BBkfEqS3817KWdC6Fdb97NyPqTY1o+UaPVvKlSd5ob08gIQod/BNtOVE4W1idRYSq rYe/fd+EECDFjOZA9LP9KX2PuX0+qYFs/EajKftSNCaFhZ/uVlebRb11pwBh9wtfUDUJ UrBTrCqJmfL3YzT/7J9AtcAgk2+1J8KScYji1CBRPhHHsuVGs4I6A6s/qMNRY8dqJd0Y hJ2Q== X-Gm-Message-State: AOAM532449Nu8+sTBugp7esmA1EjsFIf/2aREZFGHVI4PcdMS0Fuo3QD HsnQTErt913ypztMiDt4PDHU2SlNP4k= X-Google-Smtp-Source: ABdhPJwNEM4TQVDfcOqfwwqUCYDS33CTgnArS4Jj/reH2CsvjHdpUejF2aXDoe6kftMyC+K6GXs99QiHEGE= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a17:902:b703:b0:15e:ea16:2c6e with SMTP id d3-20020a170902b70300b0015eea162c6emr6043987pls.100.1652471405059; Fri, 13 May 2022 12:50:05 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 13 May 2022 19:49:59 +0000 In-Reply-To: <20220513195000.99371-1-seanjc@google.com> Message-Id: <20220513195000.99371-2-seanjc@google.com> Mime-Version: 1.0 References: <20220513195000.99371-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.550.gb090851708-goog Subject: [PATCH 1/2] KVM: x86/mmu: Drop RWX=0 SPTEs during ept_sync_page() From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, David Matlack , Ben Gardon Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Drop SPTEs whose new protections will yield a RWX=3D0 SPTE, i.e. a SPTE that is marked shadow-present but is not-present in the page tables. If EPT with execute-only support is in use by L1, KVM can create a RWX=3D0 SPTE can be created for an EPTE if the upper level combined permissions are R (or RW) and the leaf EPTE is changed from R (or RW) to X. Because the EPTE is considered present when viewed in isolation, and no reserved bits are set, FNAME(prefetch_invalid_gpte) will consider the GPTE valid. Creating a not-present SPTE isn't fatal as the SPTE is "correct" in the sense that the guest translation is inaccesible (the combined protections of all levels yield RWX=3D0), i.e. the guest won't get stuck in an infinite loop. If EPT A/D bits are disabled, KVM can mistake the SPTE for an access-tracked SPTE. But again, such confusion isn't fatal as the "saved" protections are also RWX=3D0. Add a WARN in make_spte() to detect creation of SPTEs that will result in RWX=3D0 protections, which is the real motivation for fixing ept_sync_page(= ). Creating a useless SPTE means KVM messed up _something_, even if whatever goof occurred doesn't manifest as a functional bug. Fixes: d95c55687e11 ("kvm: mmu: track read permission explicitly for shadow= EPT page tables") Cc: David Matlack Cc: Ben Gardon Signed-off-by: Sean Christopherson --- arch/x86/kvm/mmu/paging_tmpl.h | 9 ++++++++- arch/x86/kvm/mmu/spte.c | 2 ++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h index b025decf610d..d9f98f9ed4a0 100644 --- a/arch/x86/kvm/mmu/paging_tmpl.h +++ b/arch/x86/kvm/mmu/paging_tmpl.h @@ -1052,7 +1052,14 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu, s= truct kvm_mmu_page *sp) if (sync_mmio_spte(vcpu, &sp->spt[i], gfn, pte_access)) continue; =20 - if (gfn !=3D sp->gfns[i]) { + /* + * Drop the SPTE if the new protections would result in a RWX=3D0 + * SPTE or if the gfn is changing. The RWX=3D0 case only affects + * EPT with execute-only support, i.e. EPT without an effective + * "present" bit, as all other paging modes will create a + * read-only SPTE if pte_access is zero. + */ + if ((!pte_access && !shadow_present_mask) || gfn !=3D sp->gfns[i]) { drop_spte(vcpu->kvm, &sp->spt[i]); flush =3D true; continue; diff --git a/arch/x86/kvm/mmu/spte.c b/arch/x86/kvm/mmu/spte.c index 75c9e87d446a..9ad60662beac 100644 --- a/arch/x86/kvm/mmu/spte.c +++ b/arch/x86/kvm/mmu/spte.c @@ -101,6 +101,8 @@ bool make_spte(struct kvm_vcpu *vcpu, struct kvm_mmu_pa= ge *sp, u64 spte =3D SPTE_MMU_PRESENT_MASK; bool wrprot =3D false; =20 + WARN_ON_ONCE(!pte_access && !shadow_present_mask); + if (sp->role.ad_disabled) spte |=3D SPTE_TDP_AD_DISABLED_MASK; else if (kvm_mmu_page_ad_need_write_protect(sp)) --=20 2.36.0.550.gb090851708-goog From nobody Sun Jun 14 17:44:16 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 8A635C433F5 for ; Fri, 13 May 2022 19:50:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1383915AbiEMTuQ (ORCPT ); Fri, 13 May 2022 15:50:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1383923AbiEMTuJ (ORCPT ); Fri, 13 May 2022 15:50:09 -0400 Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 988672AE29 for ; Fri, 13 May 2022 12:50:07 -0700 (PDT) Received: by mail-pg1-x54a.google.com with SMTP id j187-20020a638bc4000000b003c1922b0f1bso4630658pge.3 for ; Fri, 13 May 2022 12:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=51ScGZpVXrpwP8zcndNZCQ8uZliM4Ji/XP53Uo8OU7c=; b=j65xlD3FgP3cwD6jdEtK/k0irKvl3u34nvb+fENpKx7/Pcs7SzxyfhDiSwPYBcvHxJ HYJ2voD13w7N6L1l6I69WEiM5Hrozw8ivVZPMHKXjOIe90SuRgU4IXtBJThlMjw+eyPD P6wrRsq4YlPMIx2IgQcJPGlGjEMQqR1x9oEbDulKOTO4JtU+TWvysOrILvewjIxNUIyw p9aMG6UykrJiH4/mYigct6kjHbDAcucevzWrBePGB6+GNPHLxiY8Mum/B0/ZNJo2gwYw /+SmiSE2cflOGmeZEobDDchNTXi6SqwOpaA5d/NPZair8IqZocIdW0pwx7tkYMUlkkjS 5i6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=51ScGZpVXrpwP8zcndNZCQ8uZliM4Ji/XP53Uo8OU7c=; b=DrPWfULI+YZI7GrjS3ay4/K+6b5Q8U5yw9p1wMOJDGUQ45rYKGPwQtTsscNsTam3ON nViMMioxBcyfkddSnFrWDycZ50c5rjhUk31Xag/HA4xVS8Tzpeh9VH9rYQwIosazV1oH nWKdFncHIizI+iK8xvD1rDlp/W1m4W9/NHZUgrFbsPVI26lM6PZj+nZQH+5qklbKCdfa WIPFfWpMxd7F6wl1AJbY0K4e63NgvFkAGzx7UuzUFslqDfKZuzEWj/h408J4aTLd1+SM V/xa+tQkjYyTDU8dgszb+V8SMKYi+SOtPGP3Eu32BnKdIi/9ktgsfy32AjMyDcjPJY0D +Ncw== X-Gm-Message-State: AOAM53217PEfcopY5IsYRUCcVkQL7iTgPutZlIjSorUqkiLua4FjsPbK DCJjSSuS8MYoCGIPAjnC3XpCpzZdkm4= X-Google-Smtp-Source: ABdhPJz/h/xLSJx/qn1O26fEwkmhQHGdtzjlcAYDoxIRSXTdCQEW9PB+Gzzlt3ezB+fSJoVioL9GOBDPTXU= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a17:90a:e510:b0:1d9:ee23:9fa1 with SMTP id t16-20020a17090ae51000b001d9ee239fa1mr250408pjy.0.1652471406612; Fri, 13 May 2022 12:50:06 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 13 May 2022 19:50:00 +0000 In-Reply-To: <20220513195000.99371-1-seanjc@google.com> Message-Id: <20220513195000.99371-3-seanjc@google.com> Mime-Version: 1.0 References: <20220513195000.99371-1-seanjc@google.com> X-Mailer: git-send-email 2.36.0.550.gb090851708-goog Subject: [PATCH 2/2] KVM: x86/mmu: Comment FNAME(sync_page) to document TLB flushing logic From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, David Matlack , Ben Gardon Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Add a comment to FNAME(sync_page) to explain why the TLB flushing logic conspiculously doesn't handle the scenario of guest protections being reduced. Specifically, if synchronizing a SPTE drops execute protections, KVM will not emit a TLB flush, whereas dropping writable or clearing A/D bits does trigger a flush via mmu_spte_update(). Architecturally, until the GPTE is implicitly or explicitly flushed from the guest's perspective, KVM is not required to flush any old, stale translations. Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson --- arch/x86/kvm/mmu/paging_tmpl.h | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h index d9f98f9ed4a0..d39706e46ad9 100644 --- a/arch/x86/kvm/mmu/paging_tmpl.h +++ b/arch/x86/kvm/mmu/paging_tmpl.h @@ -1076,6 +1076,15 @@ static int FNAME(sync_page)(struct kvm_vcpu *vcpu, s= truct kvm_mmu_page *sp) flush |=3D mmu_spte_update(sptep, spte); } =20 + /* + * Note, any flush is purely for KVM's correctness, e.g. when dropping + * an existing SPTE or clearing W/A/D bits to ensure an mmu_notifier + * unmap or dirty logging event doesn't fail to flush. The guest is + * responsible for flushing the TLB to ensure any changes in protection + * bits are recognized, i.e. until the guest flushes or page faults on + * a relevant address, KVM is architecturally allowed to let vCPUs use + * cached translations with the old protection bits. + */ return flush; } =20 --=20 2.36.0.550.gb090851708-goog