Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1421899iob; Thu, 5 May 2022 00:20:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymsIuQnKbX3v5nKrJEW/njSMi91qK+BHkSxZaZp2IHV5I+OENVt/phwmKxNpEXCpuD2M4t X-Received: by 2002:a17:902:c404:b0:15e:a090:dc8a with SMTP id k4-20020a170902c40400b0015ea090dc8amr20177586plk.31.1651735245437; Thu, 05 May 2022 00:20:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651735245; cv=none; d=google.com; s=arc-20160816; b=SucLFZpp/H/QC2XQoFv33bdgEgEkEK9rlbIyct6ZjJoH1E8qLrxe/14S6gmxy3oe1w mOHHGMf5iDkLW0WyEGNtl9K43nMyulNLjk//ksi6c5te8x2gAiErJbxX4seAe9gkjZ8s EnjBRSdtkOvMbWSgL/QmyxfORheazkydgLR4YeQTRJkyvP1Nj1jl/HuNB40jFal5qePi MAQLRAJ1IM1GELusaS5joZ1O/86Z1ktK4SzsEd9OT5390fb2LjDfpeZ/SYBradf8JE7h 5UyYHrM8MVGtTnNl7xjB5NT0uEITT9BenTDoTqPe8aJhakB3hTcfKusR6lS2YS02VmF8 wQZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:references :in-reply-to:mime-version:dkim-signature; bh=KpAOxxOf7dU4bz8u2U7bfhJXhIQjrXtTa2p/W0o7V3Y=; b=YwckpFGyz4iMheJoyYCxR+ljdSrNxuy4gssY1qEghWNj5QxYShsC4B4xCixLNeg9cr TTMbXZcLIGhmEoBVHxMR65NVGx0dzjm696PjcoPPtPdrFeuijJAHxatEaGtQlToVszwB wcWSSD0Gep32mPNt+NHuzxFQsSA6GkOnYCa/jDKFO/7cLcMThVCoKsUwu7urZw6XQ/KC AE2rYxzzSpkS06qQm2HhMUR0G03R68ZxgOCPGLRtUqRMYHItHFfHsV3tx7YfeAZjDlA3 dg7DwUAXIucheeENl7D5kbTzZmJ5j4RajUiH+EWFKCfVAHNAmYrkbydQ/KK84X4ZN5N9 z9pA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@eclypsium.com header.s=google header.b=coBaUgZ8; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=eclypsium.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y6-20020a1709029b8600b0015d31963594si1025629plp.291.2022.05.05.00.20.29; Thu, 05 May 2022 00:20:45 -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=@eclypsium.com header.s=google header.b=coBaUgZ8; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=eclypsium.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357057AbiEDSEe (ORCPT + 99 others); Wed, 4 May 2022 14:04:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359823AbiEDSDn (ORCPT ); Wed, 4 May 2022 14:03:43 -0400 Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA8BE67D0E for ; Wed, 4 May 2022 10:18:31 -0700 (PDT) Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-2f863469afbso23353827b3.0 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=4VxuGVL9C0FqfnG9LgutYqvbKT+Z8A7ZBkMF4kcTDBkD3YjzHouU05Q3d2yd4+4p+H 60IAoBeoAHt5HpFlSOSa2tWNk9gmQUkv/pLcYp0/Z2xlii63+1zhhbbjxBLnDSTnfFgM kcQ4FDtNRLFOH0lMNopbpuOPQwxlU6nXndn8zDIxJH3u8q3oVRiLisvA2gu3kQv1DJV+ E42tAcN9zCePjdczWPIw55X8wP23PVix8KtL0dG/Ogf1r2ls8EEQ4qfIc1luAyYc5GbD mavLOetcbFz39St9TwW6sN80LWE2wPDABIkw5g9dGQSnLIGxrhMDBcmV0a/UDQ0BuPOq 5y6w== X-Gm-Message-State: AOAM531R+6BTV0aLQlvRVv/YYl7+6jpGuaKAlGIK/SbLVYXTRDvfzmRS I96MzMa9pcajoP6YV7PXQyXheM1XNLzTC/SGC4rnvQ== 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-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 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.