On 5/6/22 10:55, Boris Petkov wrote: > 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. At least on MKTME platforms, if a device does DMA to a physical address with the KeyID bits set, it gets memory encryption. That's because all the encryption magic is done in the memory controller itself. The CPU's memory controller doesn't actually care if the access comes from a device or a CPU as long as the right physical bits are set. The reason we're talking about this in terms of CXL devices is that CXL devices have their *OWN* memory controllers. Those memory controllers might or might not support encryption. > 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. The reason we went down this per-node thing instead of something system-wide is EFI_MEMORY_CPU_CRYPTO. It's in the standard because EFI systems are not expected to have uniform crypto capabilities across the entire memory map. Some memory will be capable of CPU crypto and some not. As an example, if I were to build a system today with TDX and NVDIMMs, I'd probably mark the RAM as EFI_MEMORY_CPU_CRYPTO=1 and the NVDIMMs as EFI_MEMORY_CPU_CRYPTO=0. I think you're saying that current AMD SEV systems have no need for EFI_MEMORY_CPU_CRYPTO since their encryption capabilities *ARE* uniform. I'm not challenging that at all. This interface is total overkill for systems with guaranteed uniform encryption capabilities. But, this interface will *work* both for the uniform and non-uniform systems alike.
