Hacker News Reader

Comment by dooglius | Hacker News Reader

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.

View on HN

>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.

is that an issue when you have IOMMU?

http://research.cs.wisc.edu/multifacet/papers/micro15_border...

I think this paper presents an interesting overview of how to mitigate a subset of hw-related attack vectors. Seems really relevant.

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.

Intel has an IOMMU for PCIe. And DMA sees cleartext with (MK)TME.

There are hardware based cheats for CSGO. It’s a PCI card with some custom CPU/FPGA on it that scans and changes values inside the memory of the game.

When I read the title I hoped it would protect against that too, but no such luck then, I guess?

TBH if you have to resort to bus-based cheating in a game then I'd say it counts as a win for the anti-cheat software.

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.

https://blog.esea.net/esea-hardware-cheats/

> And DMA sees cleartext with (MK)TME.

Could you please translate this into non-expert language? Does it mean DMA granted devices can break IOMMU separation?

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.

VT-d is an IOMMU for PCIe.

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.

That's the way the 360 did it, total memory encryption, but practically DMA buffers were unencrypted.

Reply on news.ycombinator.com