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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0EF67C433EF for ; Fri, 6 May 2022 18:43:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4964D6B0071; Fri, 6 May 2022 14:43:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4445C6B0073; Fri, 6 May 2022 14:43:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 334846B0074; Fri, 6 May 2022 14:43:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 26E2D6B0071 for ; Fri, 6 May 2022 14:43:47 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 0885781FB1 for ; Fri, 6 May 2022 18:43:47 +0000 (UTC) X-FDA: 79436192094.03.2AF79FC Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf13.hostedemail.com (Postfix) with ESMTP id 3875A20027 for ; Fri, 6 May 2022 18:43:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651862626; x=1683398626; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=bL2l0mBh/m3FqkVcFUlaW65j5IuY1hIrZKH10XD8PzQ=; b=S/4N5U3GcZ2zxL3yxPqYzDO4lg5RySVwfrE8YnF9Q5EntcVl3nvWwG6t rAotkJ/SehvNCEIDJn4ivWt5Skb2D0jOeOJdQ6telvwwj+aTMxvSlB34P YnKK8bjtykTCErDSwZkTv634xaiQMybeLCKJtJFyPEI/Cqixy7iBvpggg +FpEbwn2brpm9J+YQf2jBewYLPlXh0lCvHvXG60m27YAAlBgv2UVxxNoB /0cuy7PC8CVQkD6u/9NZHBON5IMupAPd5rhKYPj145I2LwFN5f32KrX73 iKXHrH9+5wnjVqRH6QkpEHfT/hEfq4lKlBNHLYfd3+ciT62szZ9nYU+F7 g==; X-IronPort-AV: E=McAfee;i="6400,9594,10339"; a="256032595" X-IronPort-AV: E=Sophos;i="5.91,205,1647327600"; d="scan'208";a="256032595" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2022 11:43:42 -0700 X-IronPort-AV: E=Sophos;i="5.91,205,1647327600"; d="scan'208";a="695305666" Received: from hgadiraj-mobl2.amr.corp.intel.com (HELO [10.212.44.56]) ([10.212.44.56]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2022 11:43:40 -0700 Message-ID: <4bc56567-e2ce-40ec-19ab-349c8de8d969@intel.com> Date: Fri, 6 May 2022 11:43:39 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do encryption Content-Language: en-US To: Boris Petkov , Dan Williams Cc: Martin Fernandez , Linux Kernel Mailing List , linux-efi , Linux MM , platform-driver-x86@vger.kernel.org, daniel.gutson@eclypsium.com, Andrew Morton , Kees Cook , Darren Hart , "Schofield, Alison" , "Rafael J. Wysocki" , Mike Rapoport , Ard Biesheuvel , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Dave Hansen , X86 ML , alex.bazhaniuk@eclypsium.com, hughsient@gmail.com, Andy Shevchenko , Greg KH , Ben Widawsky , "Huang, Kai" References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> <6d90c832-af4a-7ed6-4f72-dae08bb69c37@intel.com> <47140A56-D3F8-4292-B355-5F92E3BA9F67@alien8.de> <6abea873-52a2-f506-b21b-4b567bee1874@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 3875A20027 X-Stat-Signature: mmyf7rk6worjaxsqaw86owy7ytgs8u9k Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="S/4N5U3G"; spf=none (imf13.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.20) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-HE-Tag: 1651862611-775696 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 5/6/22 11:25, Boris Petkov wrote: > On May 6, 2022 6:14:00 PM UTC, Dave Hansen > wrote: >> But, this interface will *work* both for the uniform and >> non-uniform systems alike. > And what would that additional information that some "node" - > whatever "node" means nowadays - is not encrypted give you? Tying it to the node ties it to the NUMA ABIs. For instance, it lets you say: "allocate memory with encryption capabilities" with a set_mempolicy() to nodes that are enumerated as encryption-capable. Imagine that we have a non-uniform system: some memory supports TDX (or SEV-SNP) and some doesn't. QEMU calls mmap() to allocate some guest memory and then its ioctl()s to get its addresses stuffed into EPT/NPT. The memory might be allocated from anywhere, CPU_CRYPTO-capable or not. VM creation will fail because the (hardware-enforced) security checks can't be satisfied on non-CPU_CRYPTO memory. Userspace has no recourse to fix this. It's just stuck. In that case, the *kernel* needs to be responsible for ensuring that the backing physical memory supports TDX (or SEV). This node attribute punts the problem back out to userspace. It gives userspace the ability to steer allocations to compatible NUMA nodes. If something goes wrong, they can use other NUMA ABIs to inspect the situation, like /proc/$pid/numa_maps.