Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp75697pxj; Wed, 23 Jun 2021 16:07:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzi2DcgcxYil3ltKqYtHJ1Imb1X4NHIDtk8hfyq6SuLlY4OoyYNfSsbzEytbYt9NwUGaum9 X-Received: by 2002:aa7:d7d3:: with SMTP id e19mr2822074eds.46.1624489663220; Wed, 23 Jun 2021 16:07:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624489663; cv=none; d=google.com; s=arc-20160816; b=syZe+VBNCgsXSzpcI1lTRREk7Ai4N+dpzRAS356sug+NsQu9Hu3xH4Yi4mhf5vQJPr HuhLleKSK35xbTB2VfJlpQ/vql4rgau6gmXFRkbX87Xu7/+rEqsocb6JPjamlmAjXcd9 Mxmp24cC3PpGLONaXmrVOGEPRjn8Rj5iErb1gV5eu0yfFskFHT8ND7noKy9CjaFnG6ca 6NUTVR5BKwMhuaR9wv6x2UFbkBTGJZiXkdcJ05KAppwXVjDkcbl8n28z7gnWr65iEKxG rPcBXVMOhHSSTWf73NBeEATH3MwZIdJmahjRCBWoNElzJjn2CxkdzfE7CN2e2oFHERwi A0Mw== 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:references:mime-version :message-id:in-reply-to:date:reply-to:dkim-signature; bh=M3ydmh5FXw/WwmZgZ0UhGBQS2xGblp3Q4P5QtrxRfkI=; b=ZlpJ6pajJYLwsB+Humn/WCXVwzbLm5RxnJTcimtaZzWU86/tPMJ+sVw+PQDmT5mBM/ Eb1U18vDeRjXa0WXtEhBUq1mefWVu5l0S/q6BUnGPZaamtiRByl6UTdg0uXx+umPVr8U CS59igSEcbp+HuiwiAp5ZeGcLCFbJtQiol+/aPXkn9WV0zvgAdZgC+iM2u5uj+1RwwHQ Am8d8Q8lqL3Xl6xfcsMfnJVVGU4cl3jJi/58OXME+eJ5b0z1FQsK2hpq8cVCcLw/RB/p ydrRzvGZnYTiqSVFq7RH42kM0IMcFXl+rLuZwD/euaa3okFtxxJpcAFgY/C57yk6k+Eu mSMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vnK9fPSg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jz2si905395ejc.656.2021.06.23.16.07.20; Wed, 23 Jun 2021 16:07:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vnK9fPSg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230030AbhFWXIa (ORCPT + 99 others); Wed, 23 Jun 2021 19:08:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229882AbhFWXI0 (ORCPT ); Wed, 23 Jun 2021 19:08:26 -0400 Received: from mail-qk1-x749.google.com (mail-qk1-x749.google.com [IPv6:2607:f8b0:4864:20::749]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2773AC061756 for ; Wed, 23 Jun 2021 16:06:08 -0700 (PDT) Received: by mail-qk1-x749.google.com with SMTP id v1-20020a372f010000b02903aa9be319adso4303205qkh.11 for ; Wed, 23 Jun 2021 16:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=M3ydmh5FXw/WwmZgZ0UhGBQS2xGblp3Q4P5QtrxRfkI=; b=vnK9fPSgKQWR5ZxNGiTOxjt1N7jAjbLXhEtcfyhBhy4nNsP17p5KlXGZRi/Dp8/x5D xoiUNjkDX5N7UtD7i4eBWfngirwXYukuiWD0nwwDZqmvrpwFJrWvvk9iwKF+XudfWMZv c8ev7fqKW/Hh8elAUTIGw2vSsPMAEq85vasEB0OKNSeWcwF5LYnQl/JTFgTyva/Fhqv3 ZYNkcuFedfXRVwt1GO6tW0a2NbPwsTs77yWMMrDtcEyVpczy6YOd/ngxJO0BS1rb8CLu RWwhbALIREUWdkbx4n9viMMkJ+JWT+jKgV/nDjjExtRRvIBp51E8DRMhxexgJzzo0Nj9 ysFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=M3ydmh5FXw/WwmZgZ0UhGBQS2xGblp3Q4P5QtrxRfkI=; b=VgyD9WMuFoheNshlqg9WlkxbnlZTZMsyIHIINAHuHloLxnNJXTWhMoW0UW/e2Zs5G6 DKV25gJBEwGEkrgmEVB1BKmaLeFXidAWE2dR7rXGBUik+6qIW4dhujiC7UoCb2Csg7kL cABYZfmDEZ63IfUzIWD6OfkkqGqWl64xtGP5R8aX06AWxd1fiGglxEpQ6dPfoqehFRcX nv1oaqXRQdS6Xh1+F83Omwy46hHS0XLVtpmCD7gKNfGPMI6CRudjfgccMy0PyYlJYx+I KZwjbjKJaRCcCnNNsOdiJWJLSrV8hxbbXjBDdAal66eJI4vW1OWkuhdGKbWs/+2jOkBS ggHQ== X-Gm-Message-State: AOAM533xJVKp8wRhFUOHl8I4zXRMNne2syfLtqdSWdtuUv7baolZl+02 DQaoT7m0F00p2RMBz8liizxtvoHMr6Y= X-Received: from seanjc798194.pdx.corp.google.com ([2620:15c:f:10:e9e:5b86:b4f2:e3c9]) (user=seanjc job=sendgmr) by 2002:a25:6f55:: with SMTP id k82mr692122ybc.490.1624489567284; Wed, 23 Jun 2021 16:06:07 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 23 Jun 2021 16:05:49 -0700 In-Reply-To: <20210623230552.4027702-1-seanjc@google.com> Message-Id: <20210623230552.4027702-5-seanjc@google.com> Mime-Version: 1.0 References: <20210623230552.4027702-1-seanjc@google.com> X-Mailer: git-send-email 2.32.0.288.g62a8d224e6-goog Subject: [PATCH 4/7] KVM: x86/mmu: Do not apply HPA (memory encryption) mask to GPAs 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, Peter Gonda , Brijesh Singh , Tom Lendacky Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ignore "dynamic" host adjustments to the physical address mask when generating the masks for guest PTEs, i.e. the guest PA masks. The host physical address space and guest physical address space are two different beasts, e.g. even though SEV's C-bit is the same bit location for both host and guest, disabling SME in the host (which clears shadow_me_mask) does not affect the guest PTE->GPA "translation". For non-SEV guests, not dropping bits is the correct behavior. Assuming KVM and userspace correctly enumerate/configure guest MAXPHYADDR, bits that are lost as collateral damage from memory encryption are treated as reserved bits, i.e. KVM will never get to the point where it attempts to generate a gfn using the affected bits. And if userspace wants to create a bogus vCPU, then userspace gets to deal with the fallout of hardware doing odd things with bad GPAs. For SEV guests, not dropping the C-bit is technically wrong, but it's a moot point because KVM can't read SEV guest's page tables in any case since they're always encrypted. Not to mention that the current KVM code is also broken since sme_me_mask does not have to be non-zero for SEV to be supported by KVM. The proper fix would be to teach all of KVM to correctly handle guest private memory, but that's a task for the future. Fixes: d0ec49d4de90 ("kvm/x86/svm: Support Secure Memory Encryption within KVM") Cc: stable@vger.kernel.org Cc: Brijesh Singh Cc: Tom Lendacky Signed-off-by: Sean Christopherson --- arch/x86/kvm/mmu/paging_tmpl.h | 17 +++++++++++++++-- arch/x86/kvm/mmu/spte.h | 6 ------ 2 files changed, 15 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h index 823a5919f9fa..9df7e4b315a1 100644 --- a/arch/x86/kvm/mmu/paging_tmpl.h +++ b/arch/x86/kvm/mmu/paging_tmpl.h @@ -20,11 +20,24 @@ * so the code in this file is compiled twice, once per pte size. */ +/* Shadow paging constants/helpers that don't need to be #undef'd. */ +#ifndef __KVM_X86_PAGING_TMPL_COMMON_H +#define __KVM_X86_PAGING_TMPL_COMMON_H + +#define GUEST_PT64_BASE_ADDR_MASK (((1ULL << 52) - 1) & ~(u64)(PAGE_SIZE-1)) +#define PT64_LVL_ADDR_MASK(level) \ + (GUEST_PT64_BASE_ADDR_MASK & ~((1ULL << (PAGE_SHIFT + (((level) - 1) \ + * PT64_LEVEL_BITS))) - 1)) +#define PT64_LVL_OFFSET_MASK(level) \ + (GUEST_PT64_BASE_ADDR_MASK & ((1ULL << (PAGE_SHIFT + (((level) - 1) \ + * PT64_LEVEL_BITS))) - 1)) +#endif /* __KVM_X86_PAGING_TMPL_COMMON_H */ + #if PTTYPE == 64 #define pt_element_t u64 #define guest_walker guest_walker64 #define FNAME(name) paging##64_##name - #define PT_BASE_ADDR_MASK PT64_BASE_ADDR_MASK + #define PT_BASE_ADDR_MASK GUEST_PT64_BASE_ADDR_MASK #define PT_LVL_ADDR_MASK(lvl) PT64_LVL_ADDR_MASK(lvl) #define PT_LVL_OFFSET_MASK(lvl) PT64_LVL_OFFSET_MASK(lvl) #define PT_INDEX(addr, level) PT64_INDEX(addr, level) @@ -57,7 +70,7 @@ #define pt_element_t u64 #define guest_walker guest_walkerEPT #define FNAME(name) ept_##name - #define PT_BASE_ADDR_MASK PT64_BASE_ADDR_MASK + #define PT_BASE_ADDR_MASK GUEST_PT64_BASE_ADDR_MASK #define PT_LVL_ADDR_MASK(lvl) PT64_LVL_ADDR_MASK(lvl) #define PT_LVL_OFFSET_MASK(lvl) PT64_LVL_OFFSET_MASK(lvl) #define PT_INDEX(addr, level) PT64_INDEX(addr, level) diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h index bca0ba11cccf..6925dfc38981 100644 --- a/arch/x86/kvm/mmu/spte.h +++ b/arch/x86/kvm/mmu/spte.h @@ -38,12 +38,6 @@ static_assert(SPTE_TDP_AD_ENABLED_MASK == 0); #else #define PT64_BASE_ADDR_MASK (((1ULL << 52) - 1) & ~(u64)(PAGE_SIZE-1)) #endif -#define PT64_LVL_ADDR_MASK(level) \ - (PT64_BASE_ADDR_MASK & ~((1ULL << (PAGE_SHIFT + (((level) - 1) \ - * PT64_LEVEL_BITS))) - 1)) -#define PT64_LVL_OFFSET_MASK(level) \ - (PT64_BASE_ADDR_MASK & ((1ULL << (PAGE_SHIFT + (((level) - 1) \ - * PT64_LEVEL_BITS))) - 1)) #define PT64_PERM_MASK (PT_PRESENT_MASK | PT_WRITABLE_MASK | shadow_user_mask \ | shadow_x_mask | shadow_nx_mask | shadow_me_mask) -- 2.32.0.288.g62a8d224e6-goog