1 |
On Thu, 2 Mar 2017 19:04:06 -0500 Rich Freeman wrote: |
2 |
> On Thu, Mar 2, 2017 at 6:26 PM, Andrew Savchenko <bircoph@g.o> wrote: |
3 |
> > On Thu, 2 Mar 2017 03:42:24 -0500 Taiidan@×××.com wrote: |
4 |
> >> |
5 |
> >> The IOMMU (theoretically) protects the CPU and memory from rogue |
6 |
> >> devices, such as the hard drive. |
7 |
> > |
8 |
> > No. Any DMA capable device can bypass IOMMU. IOMMU was not |
9 |
> > designed to protect OS from device. |
10 |
> > |
11 |
> |
12 |
> Huh? I thought protection against DMA attacks was half the reason for |
13 |
> an IOMMU in the first place. |
14 |
> |
15 |
> https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit |
16 |
|
17 |
Even the page you cited contains: |
18 |
``Some units also provide memory protection from faulty or |
19 |
malicious devices.'' |
20 |
|
21 |
Please note the word "some" here. |
22 |
|
23 |
IOMMU was created to restrict OS access to devices (and bring |
24 |
desired guest VM direct hw access when needed). While it may be |
25 |
used the other way around — to protect OS from device — it usually |
26 |
don't work this way, not every IOMMU even supports this. |
27 |
|
28 |
If we'll look further, IOMMU bypass is a part of normal operation |
29 |
of many device drivers: |
30 |
https://lists.gt.net/linux/kernel/365102 |
31 |
|
32 |
Just some real world examples, one can search the web or grep kernel |
33 |
sources for more: |
34 |
https://lwn.net/Articles/144207/ |
35 |
https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-February/115239.html |
36 |
|
37 |
And the funniest stuff: even if IOMMU can be and is configured to |
38 |
sandbox malicious devices, it can be easily bypassed in most real |
39 |
world implementations: |
40 |
https://hal.archives-ouvertes.fr/hal-01419962/document |
41 |
|
42 |
So relying on IOMMU to protect from malicious devices is even more |
43 |
naive than relying on SHA1 for crypto integrity needs. |
44 |
|
45 |
Best regards, |
46 |
Andrew Savchenko |