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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB0FEC433F5 for ; Fri, 6 May 2022 16:01:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1443296AbiEFQE7 (ORCPT ); Fri, 6 May 2022 12:04:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1387752AbiEFQEz (ORCPT ); Fri, 6 May 2022 12:04:55 -0400 Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A88869CC8 for ; Fri, 6 May 2022 09:01:09 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id s14so7858460plk.8 for ; Fri, 06 May 2022 09:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DJQuHSIAlHGIpor5c5dPdkEnVxEx8DbE7jmudCub3d4=; b=jQ7xZaZTB7N7rBpIHs/0CElGn01l9AQXdNaX6k8jXrAaJqQ25NEB9BM5bbodgfv0cZ o8v4laiuonAI3gk+YGqelG0OD+DVySSMRg63uSIqREDRrPhJMR3KSuT35wwaUS8YFYch rOrxpkfD5RuaAn4QY/2lg91WF1zOptOKzMP2JKXphcGymjOcFefW0nQQh9kP7UJMY1GG OiLAM9wX+KmK/RtQGaobXp58jVCwVZnXJF4OhYZCQMkQfwBS7mr1AOvo0j7jY7pfCkbU dUVjbhAvhfetI4VuQjiWvUUR2qZuZOW3KhYQrFs63jjEkTtnpgJAig8xUxU2zRQZBPk2 my1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DJQuHSIAlHGIpor5c5dPdkEnVxEx8DbE7jmudCub3d4=; b=gqNMv787Z90ixO/5YErw1NS/s7O6EH10ZvnOiyYWqDCbsepLj2UGIcLWpZQA5xNiMx R0/VQOChlsQT6mPAulgvkDx3fLNEZG21GBNKKLL32GW9oV2BgmHlMw/PILZANWAjpQNv poJ8uCO26V7McElZX3rtC50jktID8LGQfiWEXiCgwbuNstYm346UmlD4mxfwgl68e5FL vHCJqWDsYJfvMv5BHJfN+bwk3uGgqv7bc2gUbCWyQq3aB6ZFS9/JXa/HP2OFYxbAKg4D libYgZWvduCYH6p77g/fv8YVa2Hntdp/iNEWoZI0FeN4mvSoiQ+MwvvxIpnPxPd9T9hi SPmQ== X-Gm-Message-State: AOAM53368gHi3GofSP9Ou64M8pm5NqZTUwwtfJMZz7mV46uSAgcsWyX+ OCu5QMSl1/OECPI2I7ViKRyybQadoOQYDcSD9Cbudg== X-Google-Smtp-Source: ABdhPJzetNCcmtdzsuA7MVysj4PUmFLJT04ZeXbzfGR3fv4T/RqwwNln8yT470KW1ll1x94sH07JlabaHewBC2MmUDk= X-Received: by 2002:a17:902:da8b:b0:15e:c0e8:d846 with SMTP id j11-20020a170902da8b00b0015ec0e8d846mr4360481plx.34.1651852868602; Fri, 06 May 2022 09:01:08 -0700 (PDT) MIME-Version: 1.0 References: <20220429201717.1946178-1-martin.fernandez@eclypsium.com> <6d90c832-af4a-7ed6-4f72-dae08bb69c37@intel.com> In-Reply-To: <6d90c832-af4a-7ed6-4f72-dae08bb69c37@intel.com> From: Dan Williams Date: Fri, 6 May 2022 09:00:57 -0700 Message-ID: Subject: Re: [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do encryption To: Dave Hansen Cc: Borislav Petkov , Martin Fernandez , Linux Kernel Mailing List , linux-efi , platform-driver-x86@vger.kernel.org, Linux MM , Thomas Gleixner , Ingo Molnar , Dave Hansen , X86 ML , "H. Peter Anvin" , Ard Biesheuvel , Darren Hart , Andy Shevchenko , Greg KH , "Rafael J. Wysocki" , Mike Rapoport , Andrew Morton , daniel.gutson@eclypsium.com, hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, "Schofield, Alison" , Kees Cook , Ben Widawsky , "Huang, Kai" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 6, 2022 at 8:32 AM Dave Hansen wrote: > > On 5/6/22 05:44, Borislav Petkov wrote: > >> 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. > > So this would mean that if a system doesn't have CXL devices and has > > TME/SME/SEV-* enabled, then it is running with encrypted memory. > > > > Which would then also mean, you don't need any of that code - you only > > need to enumerate CXL devices which, it seems, do not support memory > > encryption, and then state that memory encryption is enabled on the > > whole system, except for the memory of those devices. > > CXL devices are just the easiest example to explain, but they are not > the only problem. > > For example, Intel NVDIMMs don't support TDX (or MKTME with integrity) > since TDX requires integrity protection and NVDIMMs don't have metadata > space available. > > Also, if this were purely a CXL problem, I would have expected this to > have been dealt with in the CXL spec alone. But, this series is > actually driven by an ACPI spec. That tells me that we'll see these > mismatched encryption capabilities in many more places than just CXL > devices. Yes, the problem is that encryption capabilities cut across multiple specifications. For example, you might need to consult a CPU vendor-specific manual, ACPI, EFI, PCI, and CXL specifications for a single security feature.