Re: [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do encryption

From: Boris Petkov <bp@alien8.de>
To: Dan Williams <dan.j.williams@intel.com>,
	Dave Hansen <dave.hansen@intel.com>
Cc: Martin Fernandez <martin.fernandez@eclypsium.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	platform-driver-x86@vger.kernel.org,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>, X86 ML <x86@kernel.org>,
	"Schofield, Alison" <alison.schofield@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Andy Shevchenko <andy@infradead.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Mike Rapoport <rppt@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	daniel.gutson@eclypsium.com, "H. Peter Anvin" <hpa@zytor.com>,
	alex.bazhaniuk@eclypsium.com, hughsient@gmail.com,
	Kees Cook <keescook@chromium.org>,
	Darren Hart <dvhart@infradead.org>,
	Ben Widawsky <ben.widawsky@intel.com>,
	"Huang, Kai" <kai.huang@intel.com>
Subject: Re: [PATCH v8 0/8] x86: Show in sysfs if a memory node is able to do encryption
Date: Fri, 06 May 2022 17:55:05 +0000	[thread overview]
Message-ID: <47140A56-D3F8-4292-B355-5F92E3BA9F67@alien8.de> (raw)
In-Reply-To: <CAPcyv4i73m6iPPfJE9CBdxf-OWGXahvGqvh6G-pqVO=3LB6ktQ@mail.gmail.com>

On May 6, 2022 4:00:57 PM UTC, Dan Williams <dan.j.williams@intel.com> wrote:
>On Fri, May 6, 2022 at 8:32 AM Dave Hansen <dave.hansen@intel.com> 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.

So here's the deal: we can say in the kernel that memory encryption is enabled and active.  But then all those different devices and so on,  can or cannot support encryption. IO devices do not support encryption either, afaict. And there you don't have node granularity etc. So you can't do this per node thing anyway. Or you do it and it becomes insufficient soin after.

But that is not the question - they don't wanna say in fwupd whether every transaction was encrypted or not - they wanna say that encryption is active. And that we can give them now. 

Thx.

-- 
Sent from a small device: formatting sux and brevity is inevitable.