Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1020730iob; Fri, 13 May 2022 19:55:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzGX3KZCQqOB6TqbmFggi9GbUcPzTzxB3TZ5/C9B6MGsM7QqBXYn6oveGPq/d/KdxlZqHTg X-Received: by 2002:a5d:59a6:0:b0:20c:5aa2:ae1b with SMTP id p6-20020a5d59a6000000b0020c5aa2ae1bmr6236807wrr.130.1652496951492; Fri, 13 May 2022 19:55:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652496951; cv=none; d=google.com; s=arc-20160816; b=XEqDE8ddPwdSpXL4+FgEyLPYT2oioTz+jXArFhDDu65yiWcP/mdQTSQmEIqkizGFR4 jBvoDKsrAxr0rVd1J5r3KAinFUq/caZLL03IDpmSbl2VJrHDLK1RWnqSJ3Wl/fS7Xba/ fSXQX4oTnclTiHm0UIz+b00ZcZMUFgK/4iNlTQ/TJbksNhpgWsOEyV4C72NEAsPpqIxy fdv+3BLQzv0AKWs4oIGmneYu3LUNI8CKig5UxzBQx9V96q8YtanTMHtUlMD6NNIYjHCE YHriw9iJ27M1A/5G3OFCivcvKYQ0OglncV10YH0vEeLqsy0eWnXvRbyuWetg48JrSJs2 preQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=y+/wjN2hthJC17ySiU4gVRZzaMAdl4cqYaPna/HTq9c=; b=upubT8WeO9IFtFY3xA/l4A5FkI1+dM+NStJ5l0iQ+LA9a/zbMiGEsbfuArBMzuFYmA dj+yOAbIPr5DRt6IN7cp+qxvK8ZReArLioI0zS+h2chxAZh1RJojGzqxe8O3hT3Jk7Uj NlhDpavqm3d/+c7dkjUoX7tI7h/QDliuqW8AKofz+iUheo42jZQH1ifB5Wc4zYo+3ngb qEHH3LTd56hMNqH08NqTkefp1lc7xKoevfwB+CwVHo0HPmMhEGZORb+k4mmO0WrDu0o0 HpInVsT+UyJoDeVcmXcUgqn8B/LL82JxinXMqCh59yaL4kKTrFcLXxsRrmARymbIiQbp AZCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=WEjf2vk0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id i11-20020adffdcb000000b00207bc4e77c5si3416371wrs.415.2022.05.13.19.55.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 May 2022 19:55:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=WEjf2vk0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7457F38CB5D; Fri, 13 May 2022 16:41:14 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1384580AbiEMUyv (ORCPT + 99 others); Fri, 13 May 2022 16:54:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1381755AbiEMUyt (ORCPT ); Fri, 13 May 2022 16:54:49 -0400 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F14A338BE for ; Fri, 13 May 2022 13:54:47 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id q130so11626666ljb.5 for ; Fri, 13 May 2022 13:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y+/wjN2hthJC17ySiU4gVRZzaMAdl4cqYaPna/HTq9c=; b=WEjf2vk0jU+IvGj5zt678lWoxJ0tMqIjyfMopMo8H+50y+jmTe1YdKjv4Jx3laaaHW BfUdYOat6avRaXmJreSaxYhP0vLs+fKDBTBUJawKVF75KUDXEnZkIchuAjwHBYeT1cy4 zxMdEiYq8hYbnvuk8urLbmUsNngDlTMZuucIRqIw+aiiNNP63ARTAIvpSTXRTj4bqFFr X/vIKGugG0JuJipPJFQnMCkwBNkTp81ufXbwl5aE8LQuGSUxFcdljju+0XvkundGFOCK IUCM4UruWadxkX5O5xOtYDxaWfk0bA8OKgvpMcm20c71z96N5n4pqaDhMIB+Sya5jLUo 04+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y+/wjN2hthJC17ySiU4gVRZzaMAdl4cqYaPna/HTq9c=; b=5/9Zt3KQec++wz8JQA0hjUgWme+OL96PLAwmxsiMEfiI3lFnCAxdvd1rr2QOygYj/T y5jktTTcwrAgsrZbPATgXFlT7t+yQ7T1JvMO1fC0Km9z9Fr6xGFlA86tFdw9qtV9OpTs j3YyTAGzghFuTtzKsONE9ecSqgefEmnQ6zW+C35YWE1DFr27a/YH0dFU2nhlhbv6aEki f+Bv+h8aK1JX16bBqZ9S7SmZrERg5Vb4CjptHWfn6Suna2gE33cO0Tqijr2ASR67/ooA 2ZbBj7GznnKV6lapV9SUpoqsV35naqJnLRzyVhDkvmk1GDlOY4GgCJg5GOwFZNkCxU2a XO6Q== X-Gm-Message-State: AOAM531d2uNg5vaWOWnQTd3OB25X4djI+u+1A+AvcsBjH4VlJ4rVhM6r DpWxy7fujUTmuSNvvixdyO6madInVP1Rv2QQz41t/A== X-Received: by 2002:a2e:b98b:0:b0:24f:1b64:a7b7 with SMTP id p11-20020a2eb98b000000b0024f1b64a7b7mr4049491ljp.331.1652475286071; Fri, 13 May 2022 13:54:46 -0700 (PDT) MIME-Version: 1.0 References: <20220513195000.99371-1-seanjc@google.com> <20220513195000.99371-2-seanjc@google.com> In-Reply-To: <20220513195000.99371-2-seanjc@google.com> From: David Matlack Date: Fri, 13 May 2022 13:54:19 -0700 Message-ID: Subject: Re: [PATCH 1/2] KVM: x86/mmu: Drop RWX=0 SPTEs during ept_sync_page() To: Sean Christopherson Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm list , LKML , Ben Gardon Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 13, 2022 at 12:50 PM Sean Christopherson wrote: > > Drop SPTEs whose new protections will yield a RWX=0 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=0 > 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. For some reason I found this sentence hard to read. What about this: When shadowing EPT and NX HugePages is enabled, if the guest changes the permissions on a huge page in the EPT12 to be execute-only, KVM will end shadowing it with an RWX=0 SPTE in the EPT02 when it picks up the change in FNAME(sync_page). Note that the guest can't induce KVM to create a RWX=0 during FNAME(fetch), since the only valid way for the guest to fault in an execute-only huge page is with an instruction fetch, which KVM will handle by mapping the page as an executable 4KiB page. > 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=0), 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=0. > > Add a WARN in make_spte() to detect creation of SPTEs that will result in > RWX=0 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, struct kvm_mmu_page *sp) > if (sync_mmio_spte(vcpu, &sp->spt[i], gfn, pte_access)) > continue; > > - if (gfn != sp->gfns[i]) { > + /* > + * Drop the SPTE if the new protections would result in a RWX=0 > + * SPTE or if the gfn is changing. The RWX=0 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 != sp->gfns[i]) { > drop_spte(vcpu->kvm, &sp->spt[i]); > flush = 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_page *sp, > u64 spte = SPTE_MMU_PRESENT_MASK; > bool wrprot = false; > > + WARN_ON_ONCE(!pte_access && !shadow_present_mask); > + > if (sp->role.ad_disabled) > spte |= SPTE_TDP_AD_DISABLED_MASK; > else if (kvm_mmu_page_ad_need_write_protect(sp)) > -- > 2.36.0.550.gb090851708-goog >