On Fri, May 6, 2022 at 8:32 AM Dave Hansen <dave.hansen@xxxxxxxxx> 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.
