Hacker News new | ask | show | jobs
by monkburger 516 days ago
As long as you can read and write to memory, you'll never stop cheating in multiplayer games.
1 comments

Sure, and that's why there's more and more "trusted" hardware to try and get computers to a place where their users cannot read and write to or from their own memory.
Those kinds of things tend to be their own undoing.

You added a security processor to your hardware at ring -2, but hardware vendors are notoriously bad at software so it has an exploit that the device owner can use to get code running at ring -2. Congrats, your ring 0 anti-cheat kernel module has just been defeated by the attacker's code running on your "trusted" hardware.

But in the meantime you've now exposed the normal user who isn't trying to cheat to the possibility of ring -2 malware, which is why all of that nonsense needs to be destroyed with fire.

Good luck ensuring every PCIe device with DMA access is "trusted."
IOMMU defeats DMA attacks.

There is no reason for a GPU or network driver, or anything to have arbitrary physical memory access.

If a GPU needs space for a draw-calls, allocate it in the kernel and explicitly give permission to the GPU to access it.

IOMMU gives the PCIe device access to whatever range of memory it's assigned. That doesn't prevent it from being assigned memory within the address space of the process, which can even be the common case because it's what allows for zero-copy I/O. Both network cards and GPUs do that.

An even better example might be virtual memory. Some memory page gets swapped out or back in, so the storage controller is going to do DMA to that page. This could be basically any memory page on the machine. And that's just the super common one.

We already have enterprise GPUs with CPU cores attached to them. This is currently using custom interconnects, but as that comes down to consumer systems it's plausibly going to be something like a PCIe GPU with a medium core count CPU on it with unified access to the GPU's VRAM. Meanwhile the system still has the normal CPU with its normal memory, so you now have a NUMA system where one of the nodes goes over the PCIe bus and they both need full access to the other's memory because any given process could be scheduled on either processor.

We haven't even gotten into exotic hardware that wants to do some kind of shared memory clustering between machines, or cache cards (something like Optane) which are PCIe cards that can be used as system memory via DMA, or dedicated security processors intended to scan memory for malware etc.

There are lots of reasons for PCIe devices to have arbitrary physical memory access.

I feel like in pretty much every case here they still do not need arbitrary access. The point of DMA cheating is to make zero modification of the target computer. The moment a driver needs to be used to say allow an IOMMU range for a given device, the target computer has been tainted and you lose much of the benefit of DMA in the first place.

Does a GPU need access to memory of a Usermode application for some reason, okay, the GPU driver should orchestrate that.

> We haven't even gotten into exotic hardware that wants to do some kind of shared memory clustering between machines, or cache cards (something like Optane) which are PCIe cards that can be used as system memory via DMA, or dedicated security processors intended to scan memory for malware etc.

Again, opt-in. The driver should specify explicit ranges when initializing the device.

> I feel like in pretty much every case here they still do not need arbitrary access.

Several of those cases do indeed need arbitrary access.

> The moment a driver needs to be used to say allow an IOMMU range for a given device, the target computer has been tainted and you lose much of the benefit of DMA in the first place.

The premise there being that the device is doing something suspicious rather than the same thing that device would ordinarily do if it was present in the machine for innocuous reasons.

> Does a GPU need access to memory of a Usermode application for some reason, okay, the GPU driver should orchestrate that.

Okay, so the GPU has some CPU cores on it and if the usermode application is scheduled on any of those cores -- or could be scheduled on any of them -- then it will need access to that application's entire address space. Which is what happens by default, since they're ordinary CPU cores that just happen to be on the other side of a PCIe bus.

> Again, opt-in. The driver should specify explicit ranges when initializing the device.

What ranges? The security processor is intended to scan every last memory page. The cache card is storing arbitrary memory pages on itself and would need access to arbitrary others because any given page could be transferred to or from the cache at any time. The cluster card is presenting the entire cluster's combined memory as a single address space to every node and managing which pages are stored on which node.

And just to reiterate, it doesn't have to be anything exotic. The storage controller in a common machine is going to do DMA to arbitrary memory pages for swap.