Things not to do when using an IOMMU

This presentation takes you from why there was a need for an IOMMU, what the attack surface is, and what the common missuses and mistakes are and offers advise along the way.

Back in the old days, when devices wanted to share data with the CPU, it would send it to the CPU (e.g. P/IO) and the CPU would receive it and then handle it. This worked well, for a while, but devices would become faster, and send more data. This was slow, so devices were granted direct access to memory, relieving the CPU of doing any kind of work to receive data, and all the CPU has to do is wait for memory to be written by the device. This worked well. This still works well. DMA is a wonderful thing for performance. Everything became faster, MUCH faster. Everyone was happy. Then -not that long ago- people wanted to make secure "hardware / external PCI port / virtualization". DMA is not your friend in these scenarios, e.g. your hard disk shouldn't be able to read kernel memory and read out DRM keys! There are all sorts of possible creative solutions to this problem. A common one is a thing called an IOMMU, IO Memory Management Unit. These days they come in all shapes and sizes. Conceptually, they act as gate keepers. They get to decide what device gets access to what part of physical memory and are initially programmed by the CPU. This presentation is for the poor schmo who has to port the old drivers (or make new ones utilizing an IOMMU). We've spent the last couple of years reviewing various trusted firmware's and secure devices that make use of an IOMMU to protect against DMA attacks. Many things can go wrong if you're not using the IOMMU correctly. In this presentation we address these issues systematically, showing what they look like and offering some advice.