| 1 |
On Sun, Jan 7, 2018 at 11:42 PM, <mad.scientist.at.large@××××××××.com> wrote: |
| 2 |
> You really can't fix it completely in |
| 3 |
> software on either brand, at best you are counting on code to protect code |
| 4 |
> from a hardware on intel, and more mild but still dangerous design issues |
| 5 |
> on both. |
| 6 |
|
| 7 |
As far as I can tell from the various emails/postings you can actually |
| 8 |
fix this entirely in software on AMD, though it might be better solved |
| 9 |
with a combination of microcode and software. |
| 10 |
|
| 11 |
Variant 3 doesn't impact AMD. |
| 12 |
|
| 13 |
Regarding variant 2: |
| 14 |
https://lkml.org/lkml/2018/1/4/742 |
| 15 |
(which seems to be down right now, so I'll also post:) |
| 16 |
https://webcache.googleusercontent.com/search?q=cache:i47fyooNn4UJ:https://lkml.org/lkml/2018/1/4/742+&cd=1&hl=en&ct=clnk&gl=us |
| 17 |
|
| 18 |
Regarding variant 1, I suspect this could be fixed with a call to |
| 19 |
something like CPUID, though that probably will impact performance a |
| 20 |
bit in critical code, and it probably could also be fixed by tossing |
| 21 |
in some instructions to manipulate either speculative execution or the |
| 22 |
cache (such as forcing the CPU to fetch both possible target addresses |
| 23 |
into the cache to make it impossible to tell which branch was |
| 24 |
followed). Using LFENCE (which is what Intel recommends) apparently |
| 25 |
requires an MSR setting or maybe a microcode update. I haven't |
| 26 |
actually tested CPUID on the released spectre exploit code, but I have |
| 27 |
confirmed that LFENCE doesn't fix it at all without the microcode/MSR |
| 28 |
fix. The main advantage of microcode updates would be that you could |
| 29 |
probably reduce the complexity of the software fix and maybe improve |
| 30 |
performance. Not speculatively executing something will always have |
| 31 |
some performance hit, but it could be minimal. |
| 32 |
|
| 33 |
There is also an AMD microcode update floating around (which Gentoo |
| 34 |
just deployed), and I can't figure out what it actually does, because |
| 35 |
AMD hasn't said a word about it. I can't imagine that anybody other |
| 36 |
than AMD wrote it, so I assume it went through back channels (Suse was |
| 37 |
the first to come out with it). Suse says that it disables branch |
| 38 |
prediction, and everybody else seems to be going with that description |
| 39 |
(though the upstream kernel team hasn't accepted the change). |
| 40 |
Obviously it can't completely disable branch prediction without |
| 41 |
clobbering performance so it is a mystery as to when it actually does |
| 42 |
disable it. I haven't deployed the kernel patch to load it yet so I |
| 43 |
haven't had a chance to test the spectre variant 1 code with it. |
| 44 |
|
| 45 |
There is also a lot of discussion on lkml about the right fix. We |
| 46 |
might very well end up seeing both AMD- and Intel-specific fixes with |
| 47 |
conditional logic. The two vendors don't really seem to be |
| 48 |
coordinating on this. Intel is pushing patches that apparently don't |
| 49 |
work on AMD, or aren't necessary on AMD. AMD for its part hasn't been |
| 50 |
pushing much in public at all, but has made a few list posts, and they |
| 51 |
have that mystery microcode update. |
| 52 |
|
| 53 |
I suspect that that Linux will either adopt conditional AMD vs Intel |
| 54 |
code, or will force a compromise that works on both. I have no idea |
| 55 |
what that will end up being. Once that happens I wouldn't be |
| 56 |
surprised if we see GCC adopt a fix to apply the software side of that |
| 57 |
automatically. |
| 58 |
|
| 59 |
-- |
| 60 |
Rich |
Archives