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 EA98AFA3744 for ; Thu, 27 Oct 2022 08:57:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3276F8E0001; Thu, 27 Oct 2022 04:57:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D7D68E0002; Thu, 27 Oct 2022 04:57:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F7818E0001; Thu, 27 Oct 2022 04:57:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1063C8E0001 for ; Thu, 27 Oct 2022 04:57:41 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C746FC107E for ; Thu, 27 Oct 2022 08:57:40 +0000 (UTC) X-FDA: 80066126280.30.BBEF9DE Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf17.hostedemail.com (Postfix) with ESMTP id CCE614000A for ; Thu, 27 Oct 2022 08:57:38 +0000 (UTC) Received: from zn.tnic (p200300ea9733e7cb329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e7cb:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id B7CC11EC0304; Thu, 27 Oct 2022 10:57:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1666861056; 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:in-reply-to:in-reply-to: references:references; bh=+Dn95uGpUyy1KhkBzIVhKQkCCrUE6w8O6ZoG0Tkf6u8=; b=WojIgMNXOqeXZOqiCZOflOU3lezPYEHMfd6YrCKkeVZv++P42OddnBZvTyqtS1XBWzys7n jctQye88xdiJWKoUKNVVce4O2CtcNIA5rPtDcPUKWK7HEmREnJvOrey6nTqqF9U7ME68CA hhGZInPyavGa4AN+nEjZVVpKL0AvCJI= Date: Thu, 27 Oct 2022 10:57:32 +0200 From: Borislav Petkov To: Martin Fernandez Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org, kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ardb@kernel.org, dvhart@infradead.org, andy@infradead.org, gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org, akpm@linux-foundation.org, daniel.gutson@eclypsium.com, hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, alison.schofield@intel.com, keescook@chromium.org Subject: Re: [PATCH v9 0/9] x86: Show in sysfs if a memory node is able to do encryption Message-ID: References: <20220704135833.1496303-1-martin.fernandez@eclypsium.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666861060; a=rsa-sha256; cv=none; b=uhO/xoaZuUY+qkVSoNxsBaeJ7/Km6QwlI+ls6vM/u7dUzZ6K6SKMdsn4sD/3ihM03q8qav 50zcCfIUGeDHFvR9Nuu4iCWzkl4OzTHwSfedRwjIV8Ce7qTKQ4Emp42rljzvdIwntWURNn A+3iGmz/Yb6y8pvrx+aoppCHRa6jBa4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=WojIgMNX; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf17.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666861060; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+Dn95uGpUyy1KhkBzIVhKQkCCrUE6w8O6ZoG0Tkf6u8=; b=Eb395tptq6XCJP/aibM8UjeyqaOWuyIfkj3LdbBlrV7x56zXiVn8d8dPqYmf4uGPflV1XT UhSK8/Nkydms5yB5vUlxiLxr4ZIYbVY1LNxPLv1BvWhhrvt0dhXjkPLg+CNLnDrjTWkUxZ WQAzfjdM2c2HzFGVT4OHtcfS66GaWpM= X-Rspamd-Queue-Id: CCE614000A Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=WojIgMNX; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf17.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de X-Rspamd-Server: rspam12 X-Rspam-User: X-Stat-Signature: 5zjrspiacq43q31g5weqewmunyp1z55p X-HE-Tag: 1666861058-975679 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 Thu, Oct 13, 2022 at 06:00:58PM -0300, Martin Fernandez wrote: > That's bad, because it would be nice if that attribute only depended > on the hardware and not on some setting. Why would that be bad? You want to be able to disable encryption for whatever reason sometimes. > The plan of this patch was, as you mentioned just to report > EFI_MEMORY_CPU_CRYPTO in a per node level. > > Now, I think I will need to check for tme/sme and only if those are > active then show the file in sysfs, otherwise not show it at all, > because it would be misleading. Any other idea? Well, I still think this is not going to work in all cases. SME/TME can be enabled but the kernel can go - and for whatever reason - map a bunch of memory unencrypted. So I don't know what the goal of this fwupd checking whether users have configured memory encryption properly is. It might end up giving that false sense of security... > You mean that EFI_MEMORY_CPU_CRYPTO means nothing on an AMD system? I mean, you still can disable memory encryption. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette