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