Gentoo Archives: gentoo-user

From: Rich Freeman <rich0@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] SHA-1 has just been broken
Date: Mon, 06 Mar 2017 20:28:37
Message-Id: CAGfcS_keepsLmZHW7gCO2NMHVOrwVwQE0dERE02nOiKFk8ER1w@mail.gmail.com
In Reply to: Re: [gentoo-user] SHA-1 has just been broken by Andrew Savchenko
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