From mboxrd@z Thu Jan 1 00:00:00 1970 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 10DAEC001DF for ; Sat, 22 Jul 2023 01:24:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231248AbjGVBX6 (ORCPT ); Fri, 21 Jul 2023 21:23:58 -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-Google-Smtp-Source: APBJJlFS9ME3Zza1Hm4myHB5l+fWYD2RqQf58E4vS2zZVlRLpslggxoSm25aBC9Ylr2Ofh/bnuXFeQIkSQc= 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" 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