On Mon, Mar 6, 2017 at 2:59 PM, Andrew Savchenko <birc...@gentoo.org> wrote: > On Thu, 2 Mar 2017 19:04:06 -0500 Rich Freeman wrote: >> >> Huh? I thought protection against DMA attacks was half the reason for >> an IOMMU in the first place. >> >> https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit > > Even the page you cited contains: > ``Some units also provide memory protection from faulty or > malicious devices.'' > > Please note the word "some" here. > > IOMMU was created to restrict OS access to devices (and bring > desired guest VM direct hw access when needed). While it may be > used the other way around — to protect OS from device — it usually > don't work this way, not every IOMMU even supports this.
How can it be possible to bring VM guests direct hw access without providing protection of the OS from devices? They use the same mechanism. The driver in the VM tells the card to write to address XYZ, not knowing that address XYZ in the guest is different from address XYZ in the host. The host programs the IOMMU to remap the device access to the correct address. The same mechanism would let the host remap device DMA to anywhere, or nowhere. Restricting OS access to devices seems odd unless you're talking about something like a phone with a second protected CPU. I imagine most CPUs treat IO access as a privileged operation, and certainly x86 does. So, if a process attempts to write to an IO port it will be interrupted and the OS can block the access. > > If we'll look further, IOMMU bypass is a part of normal operation > of many device drivers: > https://lists.gt.net/linux/kernel/365102 Yeah, I wasn't familiar with how poorly it is actually implemented, and obviously the IOMMU is only as good as its programming. > And the funniest stuff: even if IOMMU can be and is configured to > sandbox malicious devices, it can be easily bypassed in most real > world implementations: > https://hal.archives-ouvertes.fr/hal-01419962/document This is just an exploit, and in this case the IOMMU wasn't configured to sandbox the device at all. If it were configured with minimal access it certainly wouldn't have write access to the IOMMU configuration. > So relying on IOMMU to protect from malicious devices is even more > naive than relying on SHA1 for crypto integrity needs. So, I think we're conflating poor implementation with a flawed algorithm. SHA1 is fundamentally insecure and there is nothing you can do to make it more secure without making it something other than SHA1. IOMMU is more of a concept, but I suspect that much of the hardware in actual use probably works just fine, but nobody spends much time ensuring that Linux actually secures it. Tighter controls around the software would make it secure. This seems a bit like saying that the concept of process memory protection is flawed because at various points in time some versions of Linux have had bugs that allow processes to modify memory they shouldn't be able to modify. The concept is completely sound, but the implementation is imperfect. I think the main reason that nobody tolerates sloppy implementation of memory protection is that a lot of software is written in C and if memory protection doesn't work it is only a matter of time before the host is crashing, especially for a software developer. On the other hand, most devices aren't designed with so many bugs so by the time you're actually plugging cards into PCs they're not going to be randomly accessing RAM, and it is a lot harder to get a device to write to random RAM locations than it is to have a pointer error in your C code unless you're actually developing a device driver (and if you have a bug in a device driver you could very well have programmed the IOMMU to let the device write to the wrong RAM anyway depending on where the error lies). But, sure, I'm perfectly happy to accept your assertion that device drivers today tend to open gaping holes in the IOMMU making their security unreliable. Linux namespaces are in a similar state, eventually they should become secure but right now the sense is that they have exploitable flaws. -- Rich
