Yeah, it's done at the memory controller level. No the caches won't be encrypted, but it wouldn't make sense to; any threat model that says L* caches can be read by an adversary should also allow the register file itself to be read, and that's going to contain unencrypted data (after all, you have to decrypt the data at _some_ point).
I do wonder, though, whether the memory remains protected against adversaries who can put rogue devices on the PCIe or UPI buses; it seems that these would be able to get decrypted data.
>I do wonder, though, whether the memory remains protected against adversaries who can put rogue devices on the PCIe or UPI buses; it seems that these would be able to get decrypted data.
I don't believe Intel (whose implementation of encryption this targets) have an IOMMU for PCIe. For UPI (or whatever inter-socket protocol is going on), it wouldn't make sense to have an IOMMU since cores need permission to do arbitrary reads anyway.
There are plenty of cheats that are seemingly impossible to detect. I play Team Fortress 2 and there's at least one cheat there that, from what I've read, uses code that's unique to each instance used by a cheater. VAC seems to scan for code signatures so it doesn't detect it.
This hardware cheat makes it even harder to detect since it reads and writes directly to main memory using DMA. No drivers or software needed at all. All you possibly could detect is the PCI-ID(which can be changed) and possibly the DMA if there's an IOMMU.
No, I mean that, if the IOMMU is off or if it allows access to an address, then MKTME will treat that access exactly as though it was a normal access from the CPU. So, if the device selects the right key (the key uses some otherwise unused physical address bits), then the device will access the decrypted data.
Some NICs are able to dump data directly into the (L3) cache (DDIO on Intel), so either the L3 will have to be encrypted or the IOMMU needs to contain the crypto functionality.
Or maybe the kernel would have to except some memory for MMIO from being encrypted. That way the PCIe bus gets access to the memory without needing the keys but also can't read what it shouldn't.
AIUI Intel TME sits in the memory controller, same for MKTME. Therefore memory protection as usual protects access, and any read/write requests made to the IMC will have it use the correct keys for en/decryption. The IMC doesn't care/tell where those requests came from.
I do wonder, though, whether the memory remains protected against adversaries who can put rogue devices on the PCIe or UPI buses; it seems that these would be able to get decrypted data.