Received: by 10.223.185.116 with SMTP id b49csp1122869wrg; Wed, 14 Feb 2018 12:01:09 -0800 (PST) X-Google-Smtp-Source: AH8x227AOVEbanqtn7Af19+2UEOTR9DJ6uudwyoUoH/9GWpcj/1jEvk9UjtjcZ4iECpKpAb0G8Qf X-Received: by 2002:a17:902:9898:: with SMTP id s24-v6mr146177plp.275.1518638469369; Wed, 14 Feb 2018 12:01:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518638469; cv=none; d=google.com; s=arc-20160816; b=kevOF1IoiHQXFfnt9uSrghG2W65k/aDfDZSEvaYxJyQHLtqaFgRrJinutU0Wj0c7Uh Kd6b2Ri08Q47tQdemGhdNZC2Gtv7Asbr9wP/QCEszi6Uq7BM2MtubMBrb23CnReDkkus nWOwsawESk4fICPtgru9ZrmXlDZp6xHSxqanS+wN7P7O7Zo3ywu6I1YtDZxBByGnl1Ze 9Kcr0Yyh9pxatdTWFgX6YSDolDqyKiX4K2SrCAUWqom1uuviGVkMKZp1vnMHv2UqwNgh b9nP/Z4VYxWQWzVczFnZgoKG+06LgsRn8rihHn71crBXjvdgX8uk1uZPFqGfGLoo8Hen BsSw== 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:dkim-signature:arc-authentication-results; bh=RaCDl4yOW9wQMpy6Pjgd5uHGye+c0iUeB30+1zLLlWU=; b=uNcTovDJPSkYetv1hOu9aWfzSokTLQYt9BLtvm106VdSaH9fy1RpbGnLtkhMQIETuc s49f7sYJc/Bpkst+jHCNuAsW+/4ftqI0ZGSkHheTX8KSlDektxgUPszJIYl8G3FmERVG /d8vP+zFT1/3V4gpa4xXuY702Lcv/Q3YnC6oZzuAF6JHKTlslNz2EWk9JgAc+C6tfkAW 98dbfA7F7/6UzHYouwzTMh6aKXG8EWyy7GQm1u4yzSCLbu+SI8IxdAUqCSilOwZIje84 4Yuv7lPpHNIADEH2nFvcR/e+SLuh+Fb0idOdir55tkwHb247r59+0BUskImVT7KDS2mJ CBrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=hZm1X69k; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v8-v6si263072plk.221.2018.02.14.12.00.53; Wed, 14 Feb 2018 12:01:09 -0800 (PST) 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; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=hZm1X69k; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031843AbeBNPwD (ORCPT + 99 others); Wed, 14 Feb 2018 10:52:03 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:50809 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031649AbeBNPwB (ORCPT ); Wed, 14 Feb 2018 10:52:01 -0500 Received: by mail-wm0-f47.google.com with SMTP id k87so5787937wmi.0 for ; Wed, 14 Feb 2018 07:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=RaCDl4yOW9wQMpy6Pjgd5uHGye+c0iUeB30+1zLLlWU=; b=hZm1X69km/jEIxcD8H2lMgkE3Ide/gGFXDDrEOrBXlhuG7Vh2mfogPRPrCl7SrJEty YEI1sxU3u1JFYb8J0OOPeU0pLdJtLMfn1OxvFzvYAGogEPuTGNWNVQir5+nI/6IXKgSk lQMF7WvKqAK9EZyYg4Pnr/spTZGZJxs/Vthn9jewqjJ8C7hPRHOsIngJuKLGWMcOYApZ GK0qh81WXmoJqi7MRdxGPftzGoeZcsAbmRwRxB3YSnsxuUWDGCBry5TlivwR2UuMLKh/ 5Ze8MkobwwfQqpFhH5E5Y071EYY5bGVyNGxOHocUjDi9PijGCeOi8jEnKS6zuoG/BL60 syHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=RaCDl4yOW9wQMpy6Pjgd5uHGye+c0iUeB30+1zLLlWU=; b=DXRAm6IXZqwueE+E7Wkye7MOdvZ0X/nQ6723/SlZmbMLCLtcBYbXZIMSYOquXLXYES RrfAapIhT1EhnFRvzpxzEgDx+c6fjv5gVVxJ3ct56UJPMNoea1HYjyeAlixzS3WLTxZg cPehu2gde2Oq/dFt+af5iztCS/1w/UemkoEpy5VyqNUevHTv4Eb4cmv4NQnRHG+2HRgl nEV1QXPZyG0X3vHvhiYUdcDaLsOIh8kVargpPB8CkDwB7Wp+D/3lMk/FvZXZsWFZwAcZ DUCZycPHuF3AVleRb1AkYfjcgrmV3CWzwlLqPjMesh0O/XGcnr59SFO3auwLAoehAgbe FSRg== X-Gm-Message-State: APf1xPCVuLNHAqZzF8GEuj/+JcYJ3yeWrclVE1ElYzbgowYECjlVwoeH TQla2bQ8XqpEI/Bx6zVXaVbYZg== X-Received: by 10.80.208.214 with SMTP id g22mr7629690edf.217.1518623520059; Wed, 14 Feb 2018 07:52:00 -0800 (PST) Received: from node.shutemov.name ([178.121.192.223]) by smtp.gmail.com with ESMTPSA id d30sm9355988edd.90.2018.02.14.07.51.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Feb 2018 07:51:59 -0800 (PST) Received: by node.shutemov.name (Postfix, from userid 1000) id E073C648D520; Wed, 14 Feb 2018 18:51:57 +0300 (+03) Date: Wed, 14 Feb 2018 18:51:57 +0300 From: "Kirill A. Shutemov" To: Tom Lendacky Cc: Kai Huang , "Kirill A. Shutemov" , Ingo Molnar , x86@kernel.org, Thomas Gleixner , "H. Peter Anvin" , Dave Hansen , linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/mm: Decouple dynamic __PHYSICAL_MASK from AMD SME Message-ID: <20180214155157.e4z5vsm3237445xy@node.shutemov.name> References: <20180208125524.88795-1-kirill.shutemov@linux.intel.com> <5199949d-6795-aa55-888c-7ba8abd406e2@amd.com> <20180214042121.tza3cpvrnpztjeme@node.shutemov.name> <37cf20a3-653b-1ad7-1e65-6bed935cf325@amd.com> <1518593420.13066.11.camel@linux.intel.com> <20180214090239.cjidydeflvgeww4d@node.shutemov.name> <6f5f917e-cded-66ca-2549-f3d51dff1595@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6f5f917e-cded-66ca-2549-f3d51dff1595@amd.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 14, 2018 at 09:09:05AM -0600, Tom Lendacky wrote: > On 2/14/2018 3:02 AM, Kirill A. Shutemov wrote: > > On Wed, Feb 14, 2018 at 08:30:20PM +1300, Kai Huang wrote: > >> On Tue, 2018-02-13 at 22:57 -0600, Tom Lendacky wrote: > >>> On 2/13/2018 10:21 PM, Kirill A. Shutemov wrote: > >>>> On Tue, Feb 13, 2018 at 10:10:22PM -0600, Tom Lendacky wrote: > >>>>> On 2/8/2018 6:55 AM, Kirill A. Shutemov wrote: > >>>>>> AMD SME claims one bit from physical address to indicate > >>>>>> whether the > >>>>>> page is encrypted or not. To achieve that we clear out the bit > >>>>>> from > >>>>>> __PHYSICAL_MASK. > >>>>> > >>>>> I was actually working on a suggestion by Linus to use one of the > >>>>> software > >>>>> page table bits to indicate encryption and translate that to the > >>>>> hardware > >>>>> bit when writing the actual page table entry. With that, > >>>>> __PHYSICAL_MASK > >>>>> would go back to its original definition. > >>>> > >>>> But you would need to mask it on reading of pfn from page table > >>>> entry, > >>>> right? I expect it to have more overhead than this one. > >>> > >>> When reading back an entry it would translate the hardware bit > >>> position > >>> back to the software bit position. The suggestion for changing it > >>> was > >>> to make _PAGE_ENC a constant and not tied to the sme_me_mask. > > > > But is it really constant? I thought it's enumerated at boot-time. > > Can we step onto a problem for future AMD CPUs? > > _PAGE_ENC would be constant and it would be translated to the actual bit > that was enumerated at boot-time when writing the page table entry and > translated back to _PAGE_ENC when reading the page table entry. I'm confused. I thought that _PAGE_ENC would actual bit that indicate encryption. If we need translation, I don't see how pte_pfn() can be implemented efficiently. Getting pfn from page table entry is the path that I'm worry about. It's all over the kernel and having overhead there comes with cost. Could you write a prototype of such patch? I have hard time grasping your idea. > > In case of MKTME the bits we need to clear are not constant. Depends on > > CPU and BIOS settings. > > > > By making _PAGE_ENC constant we would effectively lower maximum physical > > address space the kernel can handle, regardless if the system has SME > > enabled. I can imagine some people wouldn't be happy about this. > > I don't see how this would lower the maximum physical address space the > kernel could handle. Bit 57 is part of the reserved page table flag > bits and if SME is not enabled the hardware bits are never used. My statement came from confusion about _PAGE_ENC value. > What I do see as a problem is a kernel built with support for SME, and > therefore _PAGE_ENC is not zero, but SME has not been enabled by the BIOS > or mem_encrypt=off is specified. In this case you can never be certain > that the translation from software bit to hardware bit and back is > correct. Take for example, pmd_bad(). Here, _KERNPG_TABLE would have a > non-zero _PAGE_ENC or'd into it. When written to a page table entry when > SME is not enabled/active, the actual hardware encryption bit would not be > set. When reading back the value, since the hardware encryption bit is > not set, the translation to set _PAGE_ENC bit won't be done and the > comparison to _KERNPG_TABLE would fail. Of course we could just eliminate > _PAGE_ENC from the comparison... > > > > > And I think it would collide with 5-level paging. > > Does 5-level paging remove bit 57 from the reserved flags? No. The same confusion. > > I would leave it as variable for now and look on this later once we would > > have infrastructure to patch constants in kernel text. > > If the MK-TME support is going to use the same approach to include the > mask/bits real time in _PAGE_ENC then maybe it would be best to get that > in first and then look to see if something could be done along the lines > of what Linus suggests or with the patchable constants. -- Kirill A. Shutemov