Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp1401717rwi; Thu, 13 Oct 2022 13:10:42 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4N8AKUwcaRRCwjSdmcxMKpNIlR5gU6v9NxqFj6DPZ03LactIQmu5USZTNzQI0SQ/AAgIxZ X-Received: by 2002:a05:6a00:2446:b0:52b:e9a8:cb14 with SMTP id d6-20020a056a00244600b0052be9a8cb14mr1545806pfj.32.1665691842314; Thu, 13 Oct 2022 13:10:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665691842; cv=none; d=google.com; s=arc-20160816; b=pW4himyYJGSw/tfg6F54KDZvs5Co9zi00GRVWTaxLSt3ppHhzk/upK9BnW361ehCuI cWxUjBhVSNtIDifO0Cx17vzGDQM7nbp2EiXy8eNWOvnUPNYa4/SHHx9FRIY08BDg+kXg kWYWRaGafIwQjgnpTg6vPNzhg03gy/UM/6gN+Dk8kiLUwGEaA5mbKK3SDlKp0lg0CBPv /MMPCLpYnvdw8YebfbbLgFJZ6A+f14ml3TNBkRglRI1uKaG9hV4Z47xbVoRfC6jBUB+l ViZj3pz0hfwW4QhJYAsliI9bZZ4O0an+j9xdgEdze1WmWuzAfJilAD7RLBq4KdFYLe0Z /wxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=AQTsN58dqUBa4kccfsq8CI7L28beVehD34GLLpg/uVc=; b=f3tBkY27MeubtXqaJMyxQGhBiEqJ8mK0+D3pvxNI+ncksc1ptFRjj16YmTsHROqYWf heN+kmkoFDE+Vhgikwi6ImZ39SOKjHVQROs0/5RLxu+oPZaLCw6lKxvHTUQcwid3N453 pvsSflOR3xUpQ8psfHzWYhhMkaj/VNIzdHBI8ScH2J8KxjiHrnNIEdfyQFKBMl58wNse YpzqS/x1BDp/0briSqgBC1ie/+notXS/ixQgxuPmm3N2CP8l1yzfxgCM3cGYGvOgxKUz fD3LvGUc6w3AoNXaJ5vor/1POkeKKJ2NUeojUYZhM9j4nykk3+TyLIkdqGw3w1C9rj4b Gc9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=AmiWO7JH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k189-20020a6384c6000000b00462b85376ecsi297016pgd.668.2022.10.13.13.10.28; Thu, 13 Oct 2022 13:10:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=AmiWO7JH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229475AbiJMTsl (ORCPT + 99 others); Thu, 13 Oct 2022 15:48:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55514 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229812AbiJMTsf (ORCPT ); Thu, 13 Oct 2022 15:48:35 -0400 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0B2518B497; Thu, 13 Oct 2022 12:48:33 -0700 (PDT) Received: from zn.tnic (p200300ea9733e733329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e733: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 B70521EC0662; Thu, 13 Oct 2022 21:48:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1665690507; 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=AQTsN58dqUBa4kccfsq8CI7L28beVehD34GLLpg/uVc=; b=AmiWO7JHwt9MRtIisXFnueA6sDdHqexmuRNDepSGd+d93yeoUVOPU4f1DbvEWzz7EjDfra 4FPPbxLDsT41p+Zh/zUV3Zn6bh1uFDGcPjPGrX2DMGu1JJf8RZbLVT0gx8e6j5cUOiDUhL z+IYAah5BFbT7jNkEze8Rktk+M2UcMo= Date: Thu, 13 Oct 2022 21:48:23 +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: <20220704135833.1496303-1-martin.fernandez@eclypsium.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 04, 2022 at 10:58:24AM -0300, Martin Fernandez wrote: > If all nodes are capable of encryption and if the system have tme/sme > on we can pretty confidently say that the device is actively > encrypting all its memory. Wait, what? If all memory is crypto capable and I boot with mem_encrypt=off, then the device is certainly not encrypting any memory. dhansen says TME cannot be controlled this way and if you turn it off in the BIOS, EFI_MEMORY_CPU_CRYPTO attr should not be set either. But that marking won't work on AMD. You really need to be able to check whether memory encryption is also enabled. And I believe I've said this before but even if encryption is on, it is never "all its memory": the machine can decide to decrypt a page or a bunch of them for whatever reason. And then they're plaintext. > It's planned to make this check part of an specification that can be > passed to people purchasing hardware How is that supposed to work? People would boot a Linux on that hardware and fwupd would tell them whether it can encrypt memory or not? But if that were the only use case, why can't EFI simply say that in its fancy GUI? Because all the kernel seems to be doing here is parrot further EFI_MEMORY_CPU_CRYPTO. And that attribute gets set by EFI so it goes and picks apart whether the underlying hw can encrypt memory. So EFI could report it too. Hmmm? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette