Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp759888imm; Fri, 15 Jun 2018 05:58:12 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ9qCab1Ayc/dMxYd9KzVOi+6ZIFlkZVgJk2E5qtt68c9gJDqfBtPmlz88pfS5EV8DT117f X-Received: by 2002:a63:62c7:: with SMTP id w190-v6mr1572814pgb.104.1529067492008; Fri, 15 Jun 2018 05:58:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529067491; cv=none; d=google.com; s=arc-20160816; b=dazxEROXVAWRN58CZE6+A7UW/FedoZfhBQxb0VNT5bvF8MN8ETb6JUok2Ao5GVC+K/ Ii/zSQKK0ogH0Nyyx+oQgaHkUsqid4ucaRm2vrwUQftUe0KxJ/n0mX6QI9INAYgLaoSc fKK37MkG1UGVG97E/tLE7IpaT/QRE2WDETh1R77LFRb0UeTgtjsgFpaJ7UK8z33KgUYK P8oquLxOB4rHugg58Cd/bCVcItSg8+QnjoAs36zZIHK7qvaZo948G2S3/PYSChK8t5gN VEdubRzqc5+tRQ2DTDkekL1kVji5KDCFjDcHKjCExiVqwHexDz90YMqe1EsxYWWi1QG0 xcvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=KXageD3DpDRIghzZmGrdBlvCWVIBssNbaBWfegjFbiU=; b=aQMJLTbmwkb+Lo25HXOjLVq8zUNHr/6AJDBvCQAKHTO+GG92YfFQTFksdtZMaCl4Dq IPLQKOSeYeSutINxeNpLGfI1WF1N6sbujX8xdWQ4RlSI5hI+mQCpYa549YhqZmSrA59W zEpUTol3l9skhZE0XFx6mlxFoytolGJCA/XfEkY2LvZ+gWFGKVDrz8fz2L7XQdmAn5Zz UTSl1Gq31wqPnioGyTQkae0S6kQGVBoSvxyoe/NjSsiNQbd0ryN00XZjj2IpkjpKWnum VhJGDoKmtOTcUO0g5BatMMc2+cHi5P5CSkXOTgK6D3b/9L+zuuA/QFUR07akbM7sExzu 2VyA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g25-v6si6475865pgn.613.2018.06.15.05.57.57; Fri, 15 Jun 2018 05:58:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936114AbeFOM5c (ORCPT + 99 others); Fri, 15 Jun 2018 08:57:32 -0400 Received: from mga17.intel.com ([192.55.52.151]:48971 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753242AbeFOM5b (ORCPT ); Fri, 15 Jun 2018 08:57:31 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2018 05:57:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,226,1526367600"; d="scan'208";a="237457085" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga005.fm.intel.com with ESMTP; 15 Jun 2018 05:57:20 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id BA5CB172; Fri, 15 Jun 2018 15:57:20 +0300 (EEST) Date: Fri, 15 Jun 2018 15:57:20 +0300 From: "Kirill A. Shutemov" To: Dave Hansen Cc: Ingo Molnar , x86@kernel.org, Thomas Gleixner , "H. Peter Anvin" , Tom Lendacky , Kai Huang , Jacob Pan , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv3 07/17] x86/mm: Preserve KeyID on pte_modify() and pgprot_modify() Message-ID: <20180615125720.r755xaegvfcqfr6x@black.fi.intel.com> References: <20180612143915.68065-1-kirill.shutemov@linux.intel.com> <20180612143915.68065-8-kirill.shutemov@linux.intel.com> <8c31f6d2-6512-2726-763e-6dd1cbb0350a@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8c31f6d2-6512-2726-763e-6dd1cbb0350a@intel.com> User-Agent: NeoMutt/20170714-126-deb55f (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 13, 2018 at 06:13:03PM +0000, Dave Hansen wrote: > On 06/12/2018 07:39 AM, Kirill A. Shutemov wrote: > > Encrypted VMA will have KeyID stored in vma->vm_page_prot. This way we > > "An encrypted VMA..." > > > 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 | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h > > index 1e5a40673953..e8ebe760b88d 100644 > > --- a/arch/x86/include/asm/pgtable_types.h > > +++ b/arch/x86/include/asm/pgtable_types.h > > @@ -121,8 +121,13 @@ > > * protection key is treated like _PAGE_RW, for > > * instance, and is *not* included in this mask since > > * pte_modify() does modify it. > > + * > > + * It includes full range of PFN bits regardless if they were claimed for KeyID > > + * or not: we want to preserve KeyID on pte_modify() and pgprot_modify(). > > */ > > -#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)) > > "signed long" is really unusual to see. Was that intentional? Yes. That's trick with sign-extension, borrowed from PHYSICAL_PAGE_MASK definition. It helps on 32-bit with PAE properly expand the PAGE_MASK to 64-bit. I'll add comment. > > +#define _PAGE_CHG_MASK (PTE_PFN_MASK_MAX | _PAGE_PCD | _PAGE_PWT | \ > > _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \ > > _PAGE_SOFT_DIRTY) > > #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE) > > This makes me a bit nervous. We have some places (here) where we > pretend that the KeyID is part of the paddr and then other places like > pte_pfn() where it's not. Other option is to include KeyID mask into _PAGE_CHG_MASK. But it means _PAGE_CHG_MASK would need to reference *two* variables: physical_mask and mktme_keyid_mask. I mentioned this in the commit message. This is more efficient way to achieve the same compile-time without referencing any variables. > Seems like something that will come back to bite us. Any suggestions? -- Kirill A. Shutemov