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 A99C2C433F5 for ; Fri, 6 May 2022 19:02:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0FCF56B0071; Fri, 6 May 2022 15:02:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0ADC46B0073; Fri, 6 May 2022 15:02:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6AC96B0074; Fri, 6 May 2022 15:02:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D34C96B0071 for ; Fri, 6 May 2022 15:02:15 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 9D0D661B7A for ; Fri, 6 May 2022 19:02:15 +0000 (UTC) X-FDA: 79436238630.09.2EEBC81 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf06.hostedemail.com (Postfix) with ESMTP id B38B71800A6 for ; Fri, 6 May 2022 19:02:10 +0000 (UTC) Received: from [127.0.0.1] (dynamic-002-247-254-212.2.247.pool.telefonica.de [2.247.254.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id B87B01EC0426; Fri, 6 May 2022 21:02:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1651863727; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x8fVcWLqPFG6/0kPKgTD+h7VgiMOQivyi/yzrWDL31E=; b=QcEfbINsxQXGmb/lPhWm6hiBU4SyfpGvhd0wkxxntZDP7ynpTevpNVvJIYEZzXegdL5Jhe dYv/chRkNgyID97Ya33eCDNS4Dgk1/2xJWPpbp9ozV/xUeWODkGvV6HLMzbqchi7qIJfp9 kra0g1/NjXuMvYmH/3hRFkUuapJjZcc= Date: Fri, 06 May 2022 19:02:03 +0000 From: Boris Petkov To: Dave Hansen , Dan Williams CC: Martin Fernandez , Linux Kernel Mailing List , linux-efi , platform-driver-x86@vger.kernel.org, Linux MM , "H. Peter Anvin" , daniel.gutson@eclypsium.com, Darren Hart , Andy Shevchenko , Kees Cook , Andrew Morton , Ard Biesheuvel , Ingo Molnar , Thomas Gleixner , Dave Hansen , "Rafael J. Wysocki" , X86 ML , "Schofield, Alison" , hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, Greg KH , Mike Rapoport , Ben Widawsky , "Huang, Kai" Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v8_0/8=5D_x86=3A_Show_in_sysfs_i?= =?US-ASCII?Q?f_a_memory_node_is_able_to_do_encryption?= User-Agent: K-9 Mail for Android In-Reply-To: <4bc56567-e2ce-40ec-19ab-349c8de8d969@intel.com> 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> <4bc56567-e2ce-40ec-19ab-349c8de8d969@intel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=QcEfbINs; spf=pass (imf06.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B38B71800A6 X-Stat-Signature: hq1oep6ohtbmpwbapx5rwbx7mrh89w1d X-HE-Tag: 1651863730-737417 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 May 6, 2022 6:43:39 PM UTC, Dave Hansen wrot= e: >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=2E >> 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=2E For instance, it lets >you say: "allocate memory with encryption capabilities" with a >set_mempolicy() to nodes that are enumerated as encryption-capable=2E I was expecting something along those lines=2E=2E=2E >Imagine that we have a non-uniform system: some memory supports TDX (or >SEV-SNP) and some doesn't=2E QEMU calls mmap() to allocate some guest >memory and then its ioctl()s to get its addresses stuffed into EPT/NPT=2E > The memory might be allocated from anywhere, CPU_CRYPTO-capable or not= =2E > VM creation will fail because the (hardware-enforced) security checks >can't be satisfied on non-CPU_CRYPTO memory=2E > >Userspace has no recourse to fix this=2E It's just stuck=2E In that cas= e, > the *kernel* needs to be responsible for ensuring that the backing >physical memory supports TDX (or SEV)=2E > >This node attribute punts the problem back out to userspace=2E It gives >userspace the ability to steer allocations to compatible NUMA nodes=2E I= f >something goes wrong, they can use other NUMA ABIs to inspect the >situation, like /proc/$pid/numa_maps=2E That's all fine and dandy but I still don't see the *actual*, real-life us= e case of why something would request memory of particular encryption capab= ilities=2E Don't get me wrong - I'm not saying there are not such use case= s - I'm saying we should go all the way and fully define properly *why* we= 're doing this whole hoopla=2E Remember - this all started with "i wanna say that mem enc is active" and = now we're so far deep down the rabbit hole=2E=2E=2E --=20 Sent from a small device: formatting sux and brevity is inevitable=2E