From patchwork Wed May 8 14:43:29 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "kirill.shutemov@linux.intel.com" X-Patchwork-Id: 10936015 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0E45A1575 for ; Wed, 8 May 2019 14:51:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 00998289A5 for ; Wed, 8 May 2019 14:51:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F235F28A7A; Wed, 8 May 2019 14:51:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A06F528AAA for ; Wed, 8 May 2019 14:51:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728238AbfEHOon (ORCPT ); Wed, 8 May 2019 10:44:43 -0400 Received: from mga06.intel.com ([134.134.136.31]:57649 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728159AbfEHOok (ORCPT ); Wed, 8 May 2019 10:44:40 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2019 07:44:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,446,1549958400"; d="scan'208";a="169656525" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga002.fm.intel.com with ESMTP; 08 May 2019 07:44:35 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 15EF358A; Wed, 8 May 2019 17:44:29 +0300 (EEST) From: "Kirill A. Shutemov" To: Andrew Morton , x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Borislav Petkov , Peter Zijlstra , Andy Lutomirski , David Howells Cc: Kees Cook , Dave Hansen , Kai Huang , Jacob Pan , Alison Schofield , linux-mm@kvack.org, kvm@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" Subject: [PATCH, RFC 09/62] x86/mm: Preserve KeyID on pte_modify() and pgprot_modify() Date: Wed, 8 May 2019 17:43:29 +0300 Message-Id: <20190508144422.13171-10-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190508144422.13171-1-kirill.shutemov@linux.intel.com> References: <20190508144422.13171-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP An encrypted VMA will have KeyID stored in vma->vm_page_prot. This way we don't need to do anything special to setup encrypted page table entries and don't need to reserve space for KeyID in a VMA. This patch changes _PAGE_CHG_MASK to include KeyID bits. Otherwise they are going to be stripped from vm_page_prot on the first pgprot_modify(). Define PTE_PFN_MASK_MAX similar to PTE_PFN_MASK but based on __PHYSICAL_MASK_SHIFT. This way we include whole range of bits architecturally available for PFN without referencing physical_mask and mktme_keyid_mask variables. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/pgtable_types.h | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h index d6ff0bbdb394..7d6f68431538 100644 --- a/arch/x86/include/asm/pgtable_types.h +++ b/arch/x86/include/asm/pgtable_types.h @@ -117,12 +117,25 @@ _PAGE_ACCESSED | _PAGE_DIRTY) /* - * Set of bits not changed in pte_modify. The pte's - * protection key is treated like _PAGE_RW, for - * instance, and is *not* included in this mask since - * pte_modify() does modify it. + * Set of bits not changed in pte_modify. + * + * The pte's protection key is treated like _PAGE_RW, for instance, and is + * *not* included in this mask since pte_modify() does modify it. + * + * They include the physical address and the memory encryption keyID. + * The paddr and the keyID never occupy the same bits at the same time. + * But, a given bit might be used for the keyID on one system and used for + * the physical address on another. As an optimization, we manage them in + * one unit here since their combination always occupies the same hardware + * bits. PTE_PFN_MASK_MAX stores combined mask. + * + * Cast PAGE_MASK to a signed type so that it is sign-extended if + * virtual addresses are 32-bits but physical addresses are larger + * (ie, 32-bit PAE). */ -#define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \ +#define PTE_PFN_MASK_MAX \ + (((signed long)PAGE_MASK) & ((1ULL << __PHYSICAL_MASK_SHIFT) - 1)) +#define _PAGE_CHG_MASK (PTE_PFN_MASK_MAX | _PAGE_PCD | _PAGE_PWT | \ _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \ _PAGE_SOFT_DIRTY | _PAGE_DEVMAP) #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE)