| 1 |
On Mon, Mar 6, 2017 at 2:59 PM, Andrew Savchenko <bircoph@g.o> wrote: |
| 2 |
> On Thu, 2 Mar 2017 19:04:06 -0500 Rich Freeman wrote: |
| 3 |
>> |
| 4 |
>> Huh? I thought protection against DMA attacks was half the reason for |
| 5 |
>> an IOMMU in the first place. |
| 6 |
>> |
| 7 |
>> https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit |
| 8 |
> |
| 9 |
> Even the page you cited contains: |
| 10 |
> ``Some units also provide memory protection from faulty or |
| 11 |
> malicious devices.'' |
| 12 |
> |
| 13 |
> Please note the word "some" here. |
| 14 |
> |
| 15 |
> IOMMU was created to restrict OS access to devices (and bring |
| 16 |
> desired guest VM direct hw access when needed). While it may be |
| 17 |
> used the other way around — to protect OS from device — it usually |
| 18 |
> don't work this way, not every IOMMU even supports this. |
| 19 |
|
| 20 |
How can it be possible to bring VM guests direct hw access without |
| 21 |
providing protection of the OS from devices? |
| 22 |
|
| 23 |
They use the same mechanism. The driver in the VM tells the card to |
| 24 |
write to address XYZ, not knowing that address XYZ in the guest is |
| 25 |
different from address XYZ in the host. The host programs the IOMMU |
| 26 |
to remap the device access to the correct address. The same mechanism |
| 27 |
would let the host remap device DMA to anywhere, or nowhere. |
| 28 |
|
| 29 |
Restricting OS access to devices seems odd unless you're talking about |
| 30 |
something like a phone with a second protected CPU. I imagine most |
| 31 |
CPUs treat IO access as a privileged operation, and certainly x86 |
| 32 |
does. So, if a process attempts to write to an IO port it will be |
| 33 |
interrupted and the OS can block the access. |
| 34 |
|
| 35 |
> |
| 36 |
> If we'll look further, IOMMU bypass is a part of normal operation |
| 37 |
> of many device drivers: |
| 38 |
> https://lists.gt.net/linux/kernel/365102 |
| 39 |
|
| 40 |
Yeah, I wasn't familiar with how poorly it is actually implemented, |
| 41 |
and obviously the IOMMU is only as good as its programming. |
| 42 |
|
| 43 |
> And the funniest stuff: even if IOMMU can be and is configured to |
| 44 |
> sandbox malicious devices, it can be easily bypassed in most real |
| 45 |
> world implementations: |
| 46 |
> https://hal.archives-ouvertes.fr/hal-01419962/document |
| 47 |
|
| 48 |
This is just an exploit, and in this case the IOMMU wasn't configured |
| 49 |
to sandbox the device at all. If it were configured with minimal |
| 50 |
access it certainly wouldn't have write access to the IOMMU |
| 51 |
configuration. |
| 52 |
|
| 53 |
> So relying on IOMMU to protect from malicious devices is even more |
| 54 |
> naive than relying on SHA1 for crypto integrity needs. |
| 55 |
|
| 56 |
So, I think we're conflating poor implementation with a flawed algorithm. |
| 57 |
|
| 58 |
SHA1 is fundamentally insecure and there is nothing you can do to make |
| 59 |
it more secure without making it something other than SHA1. |
| 60 |
|
| 61 |
IOMMU is more of a concept, but I suspect that much of the hardware in |
| 62 |
actual use probably works just fine, but nobody spends much time |
| 63 |
ensuring that Linux actually secures it. Tighter controls around the |
| 64 |
software would make it secure. |
| 65 |
|
| 66 |
This seems a bit like saying that the concept of process memory |
| 67 |
protection is flawed because at various points in time some versions |
| 68 |
of Linux have had bugs that allow processes to modify memory they |
| 69 |
shouldn't be able to modify. The concept is completely sound, but the |
| 70 |
implementation is imperfect. I think the main reason that nobody |
| 71 |
tolerates sloppy implementation of memory protection is that a lot of |
| 72 |
software is written in C and if memory protection doesn't work it is |
| 73 |
only a matter of time before the host is crashing, especially for a |
| 74 |
software developer. On the other hand, most devices aren't designed |
| 75 |
with so many bugs so by the time you're actually plugging cards into |
| 76 |
PCs they're not going to be randomly accessing RAM, and it is a lot |
| 77 |
harder to get a device to write to random RAM locations than it is to |
| 78 |
have a pointer error in your C code unless you're actually developing |
| 79 |
a device driver (and if you have a bug in a device driver you could |
| 80 |
very well have programmed the IOMMU to let the device write to the |
| 81 |
wrong RAM anyway depending on where the error lies). |
| 82 |
|
| 83 |
But, sure, I'm perfectly happy to accept your assertion that device |
| 84 |
drivers today tend to open gaping holes in the IOMMU making their |
| 85 |
security unreliable. Linux namespaces are in a similar state, |
| 86 |
eventually they should become secure but right now the sense is that |
| 87 |
they have exploitable flaws. |
| 88 |
|
| 89 |
-- |
| 90 |
Rich |
Archives