Comment by Syonyk | Hacker News Reader

Comment by Syonyk | Hacker News Reader

Parent Full thread

That's a solid writeup on the history of external DMA attacks! Very nicely done, and well worth a read.

This sort of thing is why QubesOS tends to put hardware controllers in isolated VMs and only pass access through. With a working IOMMU (any modern hardware has this), all you can get is DMA access into a VM that doesn't actually have much of interest in it, and no access into other VMs...

//EDIT: Though at a closer read, there's some that... isn't quite right, in how terms and examples are done. I'd expect better from someone doing low level security work - INB copies to a general purpose register, not a memory address, a DMA controller is a "discrete" bit of hardware, it's not very "discreet," etc. I'm not sure. This is starting to feel very AI-assisted to me. The overall concepts are fine, but a lot of the background section doesn't read reasonably, or goes off into weird weeds and... never explores them. The Intel Xeon is not a less exotic example of a DMA controller. The PC/AT platform did not have a PCI bus.

Eh. I remain convinced it's a decent enough overview of the matter, but a lot of the details just read really weird to me in the background sections. To the point that this could be an interview discussion question. "What does this get subtly wrong?"

Thank you for noticing (and reading at all). We'll try to fix these asap. "INB" is a genuine mistake, "PC/AT" should be "PS/2" and "discreet" is a translation error.

Some Xeon chips have additional DMA controllers "onboard".

No AI was used, each mistake here is handmade with love and 100% organic :) We wanted to give a decent (but not too deep) historical overview, however first and foremost we introduce new vector to conduct the attack.

Thanks for responding! Welcome to HN!

I write long form text posts as well, so I appreciate the format. It just had a number of things that didn't seem quite right to me, being in similar deep technical weeds.

Now try the attack on Qubes. ;)

Generally speaking, PS/2s did not have a PCI bus either, although some of them did have an ISA bus.

(Both ISA and PS/2 microchannel would allow busmastering of exactly what your article describes, though, so the point might as well stand - for that matter, so would other buses like EISA and VESA local bus.)

Well yeah, PS/2 didn't have PCI, they got MCA. Then MCA-led takeover failed, and industry adopted PCI instead. That's the thought process. We'll have to come up with better wording, I guess

Russian version of this article, published slightly earlier AFAIU ( https://habr.com/ru/companies/pt/articles/863536/ ) does not look very AI-assisted, but still contains some of the weird moments you mentioned.

"discreet" looks like translation error, in russian version word "special" is used. PC/AT is still there, as well as Xeon example (latter does not seem "not quite right" to me)

Yeah, there were a few words early on that struck me as "This is a non-native English speaker" sort of translation issues, which don't bother me in technical writing like this. But when they started doing INB/OUTB examples as memory addressed instructions, vs copying into a register... I get the point being made, but also, that's not a translation error. Don't use the "This is an actual instruction" font if you're not quoting actual instructions that exist on the hardware. "inb 0x8, 0xFF" is not a valid x86 instruction, not even close.

Anyway, I'd also like to see some of their source, or hardware diagrams, but... it'll come out eventually, I suppose.

Proper IOMMU configuration and assigning anything with DMA to a disposable service VM still solves a lot, though at least these attacks require physical access. So far. I'm sure someone, at some point, will release a SD Express card with awful enough firmware that you can pivot through it for a software-only attack on this sort of system.

With a working IOMMU (any modern hardware has this)...

I agree with the "IOMMU" part, but my experience with the "working" part is more hit-or-miss.

> The Intel Xeon is not a less exotic example of a DMA controller.

The full context is:

> The DMA controller is just used as an “memcpy() hardware accelerator”. And this is not a joke. Sometimes those blocks are used in microcontrollers to copy large swathes of data inside RAM. A less exotic example of this we can mention are Intel Xeon platforms.

I interpreted this as a reference to the Data Streaming Accelerator (DSA) [1], which is a programmable DMA peripheral on the SoC that can be used to accelerate writes to and from I/O devices (amongst other things).

[1] : https://www.intel.com/content/www/us/en/products/docs/accele...

But they never expand on that in the article. They just drop the Xeon reference there, and carry on as though they'd never said a thing about a Xeon.

I agree, that's probably what they're referring to, but it was neither needed to make the points they were trying to make, nor expanded into something to further strengthen the points made.

> all you can get is DMA access into a VM that doesn't actually have much of interest in it, and no access into other VMs...

Of course you have to ensure that you harden the interface between that VM and the host sufficiently.

Sure, this is literally the core of Qubes security model. They run a massively stripped down Xen that eliminates a lot of the complex interfaces, the old legacy hardware emulation models, etc. If you can pivot through Xen, you own Qubes entirely - you can get to Dom0, and do whatever you want. They've gone very much out of their way to ensure that the VM to hypervisor interfaces are as limited as possible, and as hard as possible.

Reply on news.ycombinator.com