On Tue, Jan 9, 2018 at 4:26 AM, Wols Lists <antli...@youngman.org.uk> wrote: > On 08/01/18 13:52, Rich Freeman wrote: >> 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. > > Probably not much point co-operating. The *internals* of AMD chips and > Intel chips are very different. I suspect both of them have a RISC core > with an x86 instruction set interpretation layer, but that's where the > similarities end ... >
The fact that their internals are very different is EXACTLY why they need to cooperate. Spectre cannot be remediated in existing CPUs with a microcode update only. It might not even be possible to completely fix it in future CPUs with only a hardware change. Spectre remediation (at least at present) requires software changes as well. Software is written to the ISA, and both Intel and AMD share a common ISA for the most part. It is impossible for a programmer to know how the internals of the CPU actually work, so they write their code to the ISA specifications. If the ISA says to insert an LFENCE instruction immediately after every bounds check then programmers (or at least compiler designers) will do just that. If it says to insert a CPUID instruction after every bounds check then that is what programmers/compilers will do. However, if one of the major vendors tells everybody to do one thing, and the other tells everybody to do another, and each writes their microcode fixes to work only their way, then programmers are stuck trying to reconcile them. The two vendor CPUs are no longer truly instruction-set compatible for typical software. Adding a lot of conditional branching anytime there is a bounds check to try to detect the CPU and deal with it isn't a great workaround either, because branching is what causes the problem in the first place - it would be better to determine the correct fix at compile-time and not runtime. Intel and AMD don't need to agree on how to fix the internals of their CPUs. What they do need to agree on is the changes that need to be made in the ISA. Since AMD has been relatively quiet I suspect they intend to just let Intel define the fix, and then quietly patch their CPUs to accept the same fix, or at least to not have any issues when the Intel fix is used. However, the fact that they quietly issued a microcode update doesn't go along with that, especially since they haven't provided any clarification on what it does, or whether anything needs to be done with software to take advantage of it. Intel, while not being all that cooperative, has at least issued unambiguous statements on what needs to be done to remediate everything. -- Rich
