Received: by 2002:a05:6358:701b:b0:131:369:b2a3 with SMTP id 27csp621254rwo; Fri, 21 Jul 2023 18:41:25 -0700 (PDT) X-Google-Smtp-Source: APBJJlGpCe9YLp+RnlbZMA9TBTa+fvgtwJ/zllpSkSC431qgCbIejXJ1jwDKXnJcMFdZrj2OHwSM X-Received: by 2002:a17:906:76cd:b0:993:f12a:39ce with SMTP id q13-20020a17090676cd00b00993f12a39cemr3119033ejn.15.1689990085282; Fri, 21 Jul 2023 18:41:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689990085; cv=none; d=google.com; s=arc-20160816; b=FdH0QE6OXNxj1UY9MKnxp3yBXx48KTrntBnsNplTEneEs0Lv/x3bCvbf/ZSQfBSEcf z76xcFhVS3XI6qqp25JNx5i3wEWX+W6FS6CxfMONEa+SZ7izhAfbcZbaZSvQ0SYuQEAV v+HXWwe0w9xpkxOkAROmLoorRBnGuKHjcLq0o6QV4O7V6y7184pJMJORjAuZbvLtIa1i bhFpRXCCA64utEAcS3h3lvcDAkYOYHIAmTh+yBPbqpoZmyhilhCja5v/dgEO38zlcfnW nxQD/s9kIwty3vx+ZtSekhwk2tOg9232l9EBNEhvpJPpgZFUGcBB/bgrEMHGGnoMSMS7 Odig== 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:mime-version:date :reply-to:dkim-signature; bh=pjOGI0rtHJ0Xllp/eOzp2m4a8FZifh6yDGUlOPnX5JQ=; fh=+wFND6X2PweTsJwZ99iP2DHiwxyX/zx7C8kEbHFvmqg=; b=tJJv59GjiWg7U4mMJyVmou2zs3gYpnc7u6NpAQoBSGnyc/sqEa9wCe1veUGgKiT5mX U8NphXABjUeCzMK5otfurCa8RJ62yjwwrH+wTMRPvDrP0QxIB2jkF6pSNqSXudBGPMc1 YhLq605r347o/UuKqN81u5hY/9vmKnXyEp9p6N3yWyIDVqWPk9JllbZgTUtuybhFhqR1 olW7xTFYchLSubTEHLm1MwUHRQLlzTFYqfnsFLv6aVJUZ99Hr4rzRW248DEn7eN99SrM +v+cnn9G9imqQ0oHE/+YHXAOaMiKGftBPBowIyKpu7Kxa0ronuxC0yN77GDAyDnbYcsb qGsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=mR41XkAU; 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 e13-20020a170906248d00b009874842217bsi2840129ejb.441.2023.07.21.18.41.01; Fri, 21 Jul 2023 18:41:25 -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=20221208 header.b=mR41XkAU; 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 S230454AbjGVBX5 (ORCPT + 99 others); Fri, 21 Jul 2023 21:23:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229763AbjGVBXz (ORCPT ); Fri, 21 Jul 2023 21:23:55 -0400 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD3783AB0 for ; Fri, 21 Jul 2023 18:23:52 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-583b256faf5so4845447b3.1 for ; Fri, 21 Jul 2023 18:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689989032; x=1690593832; h=cc:to:from:subject:message-id:mime-version:date:reply-to:from:to:cc :subject:date:message-id:reply-to; bh=pjOGI0rtHJ0Xllp/eOzp2m4a8FZifh6yDGUlOPnX5JQ=; b=mR41XkAUtB4o5mYfqLuTYY+l4LWmXM/Qu71oinEDo21mv55ssG0ngGgmvah527PCli hJI1iJlYTvgiwcTV9rH+o6xwTjaV0LPYpmh/VPDl06sIOkON5t/dPvpAIZLzDKXl5MVR wk0DRTFkMJGHmdP8Xc0HklC4SD08YDHgwfiC8z0rH0W55H5Sm+BLqkLbPqgICPEurj9S qEeqgJvoZmTplAu57lhg1rCV0NysaIS8CpI5XWXffSVcIFIhHcjBOA6ry+dmII+WofFE hdTez1UkIbIwKp27TsdAoG3Z0+cqopYavklupVmTkLi3s5pHzEX9fojy9kZxZ7aIspVY RayQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689989032; x=1690593832; h=cc:to:from:subject:message-id:mime-version:date:reply-to :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pjOGI0rtHJ0Xllp/eOzp2m4a8FZifh6yDGUlOPnX5JQ=; b=g0dhIkkFWMN7XiJGomtQ+7CtTNyxgM6ffUTmThCRhw8ER2+SkQ92tjePy9mWZJeh9h INm+C02COQdsI6FzFjKEx9LpJIE/dimTb1oBmVs/C5FSZis25iccZ6uGCVq0714SaXoQ yUE3AoAd8ydp3h6LhN43xWr+mEEAHw1VRBC9GfHfCPpGdWJLvqoNzSXefCx2d4rs2Tu5 FhyCfGfYwBhb2LpOk6av+vql5Z4C+j7Iw3CehP9YPZOXCIKgt5wK2ZqwsKY7aLZA6OGy 7hg8tPnu1EAWSOBi1X56aIJ9Srfpix487xm1uDLQz/WdH0wTLC1zEvThtst3uwCx6pg6 leWQ== X-Gm-Message-State: ABy/qLb+bHX8Vyc0ETogHJu1pQJ8XM3Ng7g79tkHdXumA8tXB8Gnjyc8 lBwt5DIjQb76IBvvLcRGQM+MgJCcE5Q= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:3086:b0:57a:6bb:c027 with SMTP id ez6-20020a05690c308600b0057a06bbc027mr20450ywb.1.1689989032191; Fri, 21 Jul 2023 18:23:52 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 21 Jul 2023 18:23:45 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.41.0.487.g6d72f3e995-goog Message-ID: <20230722012350.2371049-1-seanjc@google.com> Subject: [PATCH 0/5] KVM: x86/mmu: Don't synthesize triple fault on bad root From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Reima Ishii Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RISK_FREE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, 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 Rework the handling of !visible guest root gfns to wait until the guest actually tries to access memory before synthesizing a fault. KVM currently just immediately synthesizes triple fault, which causes problems for nVMX and nSVM as immediately injecting a fault causes KVM to try and forward the fault to L1 (as a VM-Exit) before completing nested VM-Enter, e.g. if L1 runs L2 with a "bad" nested TDP root. To get around the conundrum of not wanting to shadow garbage, load a dummy root, backed by the zero page, into CR3/EPTP/nCR3, and then inject an appropriate page fault when the guest (likely) hits a !PRESENT fault. Note, KVM's behavior is still not strictly correct with respect to x86 architecture, the primary goal is purely to prevent triggering KVM's WARN at will. No real world guest intentionally loads CR3 (or EPTP or nCR3) with a GPA that points at MMIO and expects it to work (and KVM has a long and storied history of punting on emulated MMIO corner cases). I didn't Cc any of this for stable because syzkaller is really the only thing that I expect to care, and the whole dummy root thing isn't exactly risk free. If someone _really_ wants to squash the WARN in LTS kernels, the way to do that would be to exempt triple fault shutdown VM-Exits from the sanity checks in nVMX and nSVM, i.e. sweep the problem under the rug. I have a KUT test for this that'll I'll post next week. Sean Christopherson (5): KVM: x86/mmu: Add helper to convert root hpa to shadow page KVM: x86/mmu: Harden new PGD against roots without shadow pages KVM: x86/mmu: Harden TDP MMU iteration against root w/o shadow page KVM: x86/mmu: Disallow guest from using !visible slots for page tables KVM: x86/mmu: Use dummy root, backed by zero page, for !visible guest roots arch/x86/kvm/mmu/mmu.c | 88 ++++++++++++++++++--------------- arch/x86/kvm/mmu/mmu_internal.h | 10 ++++ arch/x86/kvm/mmu/paging_tmpl.h | 18 ++++++- arch/x86/kvm/mmu/spte.h | 12 +++++ arch/x86/kvm/mmu/tdp_iter.c | 11 +++-- arch/x86/kvm/mmu/tdp_mmu.c | 2 +- 6 files changed, 93 insertions(+), 48 deletions(-) base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c -- 2.41.0.487.g6d72f3e995-goog