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 41299C433EF for ; Wed, 4 May 2022 17:18:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A9B6C6B0071; Wed, 4 May 2022 13:18:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A49686B0073; Wed, 4 May 2022 13:18:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9105F6B0074; Wed, 4 May 2022 13:18:32 -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 82F1F6B0071 for ; Wed, 4 May 2022 13:18:32 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4C227156F for ; Wed, 4 May 2022 17:18:32 +0000 (UTC) X-FDA: 79428719664.13.E6F80F3 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf24.hostedemail.com (Postfix) with ESMTP id D81E41800A6 for ; Wed, 4 May 2022 17:18:25 +0000 (UTC) Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-2f7d7e3b5bfso23019827b3.5 for ; Wed, 04 May 2022 10:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eclypsium.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KpAOxxOf7dU4bz8u2U7bfhJXhIQjrXtTa2p/W0o7V3Y=; b=coBaUgZ8nAbhXF75cSRyU/lfmoIyr1FUM46WAH6fhjtBUXT/Nx8Wf7MV8Dkh8xh9oK X8dtKhwAxw1EvyVSgDqRhnWfwYnP70rdyajaB20fsCPMOY3lDeCvLMUSi5bOMKP9CYc8 kJmVraTaif4Gm8PiIZDP5Mtbedu7YE+PK9rDpgY5aLIOmsUkbbo3MaDj6S5fFUFlRE16 bz+y6H0we9f0u70e1e/TTPl8L21b+xD8IIXg9rE0Wg3yRpdSJElYRj9sMCaFT8XmINNF nKHUqHXJlSI7aRuFyBrCcUmmSxL15dIdU76ZffLWHdnK79t7Yhd+fhqvMDLsPiFsPQug 1dJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KpAOxxOf7dU4bz8u2U7bfhJXhIQjrXtTa2p/W0o7V3Y=; b=7mqqQPWQtTcVUdxsPdpl3xDwndhKPa7WqPbmPlc0MkeXTWxYSnhZk4L8x0bDFLer7z pnczqrP6bDuSjlCYsIiUg8Yu4ckFRYsynZNMc6zUeOy0D45OexSsXVb8ANptym63tfet VxRXVc8FcE1Ql5uy+x/BxeRymYa5mSb4QtJKzCMltuzAcRrTE6FOyH94Ao9hhmYNIdBT aFtW9rGJ2H0JYOYBjhqiiPAo2DM+BOwtYGf4VGD5/9uEwy+4kFtjnKzTK/5cErFRWHPc Hg8CpXuOhPwu3OflvV+OEEkbdA55Ip7hdumRd+9VxFug/rqGGwdtECEpTm/4dDfFZsjn sNJQ== X-Gm-Message-State: AOAM532fz9o23oOps36vryzdS+GDnnUhO/KSxHAYOpFlhG+Kxb0/hNPZ 5mBuQmlPi35Upwd0fsD7ZMn4uDaFdLax40RxEirIOQ== X-Google-Smtp-Source: ABdhPJxj+owUt6AMy/MB/Z+aRoj7N/0E+jAUcqThp2az4JwzbWnd6PCSs6wI5f+Eju46sPuKqYdXySzwau+YXOo+daM= X-Received: by 2002:a81:cf02:0:b0:2d0:b68c:cf30 with SMTP id u2-20020a81cf02000000b002d0b68ccf30mr21128156ywi.510.1651684711003; Wed, 04 May 2022 10:18:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:10a:0:0:0:0:0 with HTTP; Wed, 4 May 2022 10:18:30 -0700 (PDT) In-Reply-To: References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> From: Martin Fernandez Date: Wed, 4 May 2022 14:18:30 -0300 Message-ID: Subject: Re: [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do encryption To: Borislav Petkov Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D81E41800A6 X-Stat-Signature: xty5zd6kkct1s1eu16am4agstyhbx4ny X-Rspam-User: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=eclypsium.com header.s=google header.b=coBaUgZ8; spf=pass (imf24.hostedemail.com: domain of martin.fernandez@eclypsium.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=martin.fernandez@eclypsium.com; dmarc=pass (policy=quarantine) header.from=eclypsium.com X-HE-Tag: 1651684705-357120 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/4/22, Borislav Petkov wrote: > On Fri, Apr 29, 2022 at 05:17:09PM -0300, Martin Fernandez wrote: >> Show for each node if every memory descriptor in that node has the >> EFI_MEMORY_CPU_CRYPTO attribute. >> >> fwupd project plans to use it as part of a check to see if the users >> have properly configured memory hardware encryption >> capabilities. fwupd's people have seen cases where it seems like there >> is memory encryption because all the hardware is capable of doing it, >> but on a closer look there is not, either because of system firmware >> or because some component requires updating to enable the feature. > > Hm, so in the sysfs patch you have: > > + This value is 1 if all system memory in this node is > + capable of being protected with the CPU's memory > + cryptographic capabilities. > > So this says the node is capable - so what is fwupd going to report - > that the memory is capable? > > From your previous paragraph above it sounds to me like you wanna > say whether memory encryption is active or not, not that the node is > capable. > > Or what is the use case? The use case is to know if a user is using hardware encryption or not. This new sysfs file plus knowing if tme/sev is active you can be pretty sure about that. >> It's planned to make it part of a specification that can be passed to >> people purchasing hardware > > So people are supposed to run that fwupd on that new hw to check whether > they can use memory encryption? Yes >> These checks will run at every boot. The specification is called Host >> Security ID: https://fwupd.github.io/libfwupdplugin/hsi.html. >> >> We choosed to do it a per-node basis because although an ABI that >> shows that the whole system memory is capable of encryption would be >> useful for the fwupd use case, doing it in a per-node basis gives also >> the capability to the user to target allocations from applications to >> NUMA nodes which have encryption capabilities. > > That's another hmmm: what systems do not do full system memory > encryption and do only per-node? > > From those I know, you encrypt the whole memory on the whole system and > that's it. Even if it is a hypervisor which runs a lot of guests, you > still want the hypervisor itself to run encrypted, i.e., what's called > SME in AMD's variant. Dave Hansen pointed those out in a previuos patch serie, here is the quote: > CXL devices will have normal RAM on them, be exposed as "System RAM" and > they won't have encryption capabilities. I think these devices were > probably the main motivation for EFI_MEMORY_CPU_CRYPTO.