Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp4754773rwl; Mon, 10 Apr 2023 16:39:26 -0700 (PDT) X-Google-Smtp-Source: AKy350bFUDpwvPTjRz6529dzXmmFUC45H+HhWrpRG6D9EMm7twq66oB1se/WayfamMKWSQ0CNjw5 X-Received: by 2002:a17:90b:1801:b0:23d:5196:eca8 with SMTP id lw1-20020a17090b180100b0023d5196eca8mr1274662pjb.20.1681169966212; Mon, 10 Apr 2023 16:39:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681169966; cv=none; d=google.com; s=arc-20160816; b=BiYoYQqzUZ488UIQywQMi50ud9VAzbuYIr2tbf4Qa0jdc/f8142aeQVn7jk+svzxbA 6HHlJUEyKsiL9f9XN1fg9aCk/axbNA5xFlDsYdr5zl9JWCy5PD+WmJce/wH5Xpj7X/TK jFNvq8Pjw9pmYvcpgpHVlMtZFW5A3lu210dD/FJ7UcHp8Q77GpeSIJOs7TLzu7lSgG2O YX/Tfjc6EdrJK8XyoiTdC2CsnNTVkRHY8d0XEWN0D7BYqciawKktvaabsSvise/+p1xR xRJvUKg/9po2j9QjScfWV12k+PYdKRHqdjdGlDTxBPpmPTfRib1IizbFALwWkvXxxYw5 nRCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=ENQIX3T8ZFxG064pag52+qn+mmKF1BPSsOyPJOmvcNs=; b=dDAPn4wpVfv2zG7YH/gAZ5oxmuSG+IvzbiZpXCYP2HFi7Sg/MTkgTM7Lur5Aeuyb72 1N4a+OhHW05gRrGwFngbbtEVyZKSzecOX7VXi1AR4HM5zSlWb9Ij2qMoJSCfRzulfvE8 eWW1GCktmtg4z6GgGg07ETj+v7j7utDkZ7OBRB/Ivt1fdsvSkf+AtduUI4kRS4OzBTSn KQJKHNBqgu5SK8skWcGRNWkdxJEpQVmmxVlj3CWZPcIZM30si1Vq7EP3VG6rDrWYmLw5 EBnfOH+KuHhOf3M/uNZhAWVNgMlInBWSuO+PfC3EbV06QRU0cFQr4mj7rjYKVTHweVS3 ceNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Czw325as; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 33-20020a631861000000b0051423af249fsi5871738pgy.304.2023.04.10.16.39.14; Mon, 10 Apr 2023 16:39:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Czw325as; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230017AbjDJXaO (ORCPT + 99 others); Mon, 10 Apr 2023 19:30:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230007AbjDJXaM (ORCPT ); Mon, 10 Apr 2023 19:30:12 -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 C880CB4 for ; Mon, 10 Apr 2023 16:30:11 -0700 (PDT) Received: by mail-pj1-x1049.google.com with SMTP id 98e67ed59e1d1-2467729fc4bso250421a91.1 for ; Mon, 10 Apr 2023 16:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1681169411; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=ENQIX3T8ZFxG064pag52+qn+mmKF1BPSsOyPJOmvcNs=; b=Czw325as9KxJkiOXwRGf1MHXpktzXb9uTyUZJqC1AGiYWHseNVrs7HU/KFBjdZ6zhJ 9QDAatCngZSY40OjjgN01R3m3MTIvDztDBWbk4Hwqwo/oPjicJL0OsLpUw9e3Sxu1ILw oXuj8v9cunaddpUW/5LLkJrLyCCEBgcq9PdqD4jPZnJomoHDobsIKoHb/fBdcaHyBJu+ IvB7K5pxmExyhrFoLfad/vmnTtIMvpzNB8a2Su+716q8vQLzWoWZI3F/mtf7QtSgKjxI gsCUJcQgzbKd6fFgrd5cW7fRZcV7rq0PpFuAQfmM54kf55+7AMwrMeFdcC/e/YoK5ekc sLkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681169411; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ENQIX3T8ZFxG064pag52+qn+mmKF1BPSsOyPJOmvcNs=; b=F44My6Ux8QpnRwfImviLrKzFm4UFS1/RoUdWY79X1MZiOgBMfHqvne81C+nicPd7YE XdAzDs1dGWvaUZIpJp/V6bt4X5Pc+Wqa42hYIfXDGbmaIt/4Dy0iA9isfZ8c3nG8FI8x 9M/xleRuRbHbQKZl3vpGOiS7rzlycsqHzjd9tPDBDueMruVsrIUDvIXetJNNfzlRh8EH f5sejEJ4dwbZPVFtNLgOOuTp+E0WSAecEn44sqt1Pu/oWl/C1rHbCSlobA47PKKmfAqP A6lIMsHt5L9QGTnYErttIjU4L/xTREGXow6e6mHMiDGvi54ugzsgStAAoYGctxvYlk5+ Adqg== X-Gm-Message-State: AAQBX9eGJcC7xYO6k6BoIsDhEVlWp04NuEZor0m6DChnRtiiKHH8hIWp nbfZydaL0h7VOApl43XONOo/qB42RVk= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:1383:b0:622:b78d:f393 with SMTP id t3-20020a056a00138300b00622b78df393mr4175521pfg.2.1681169411306; Mon, 10 Apr 2023 16:30:11 -0700 (PDT) Date: Mon, 10 Apr 2023 16:30:09 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230405002608.418442-1-seanjc@google.com> Message-ID: Subject: Re: [PATCH] KVM: x86/mmu: Refresh CR0.WP prior to checking for emulated permission faults From: Sean Christopherson To: Mathias Krause Cc: Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-7.7 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 Wed, Apr 05, 2023, Mathias Krause wrote: > On 05.04.23 02:26, Sean Christopherson wrote: > > If CR0.WP may be guest-owned, i.e. TDP is enabled, refresh the MMU's > > snapshot of the guest's CR0.WP prior to checking for permission faults > > when emulating a guest memory access. If the guest toggles only CR0.WP > > and triggers emulation of a supervisor write, e.g. when KVM is emulating > > UMIP, KVM may consume a stale CR0.WP, i.e. use stale protection bits > > metadata. > > This reads a little awkward for a non-native speaker. Heh, I don't think being a non-native English speaker has anything to do with it being awkward, I also found it confusing when I reread it :-) I rewrote the changelog to the below when applying. Holler if it's still weird, I can easily fixup and force push the changelog. Thanks! Refresh the MMU's snapshot of the vCPU's CR0.WP prior to checking for permission faults when emulating a guest memory access and CR0.WP may be guest owned. If the guest toggles only CR0.WP and triggers emulation of a supervisor write, e.g. when KVM is emulating UMIP, KVM may consume a stale CR0.WP, i.e. use stale protection bits metadata. Note, KVM passes through CR0.WP if and only if EPT is enabled as CR0.WP is part of the MMU role for legacy shadow paging, and SVM (NPT) doesn't support per-bit interception controls for CR0. Don't bother checking for EPT vs. NPT as the "old == new" check will always be true under NPT, i.e. the only cost is the read of vcpu->arch.cr4 (SVM unconditionally grabs CR0 from the VMCB on VM-Exit).