On Thu, Apr 5, 2018 at 12:34 PM, Mick <michaelkintz...@gmail.com> wrote: > > Does the lack of a microcode patch mean the in-kernel and other software fixes > won't be sufficient to protect PCs running these old CPUs?
I'm interested if somebody has a more informed answer, but my guess is that it would result in a less efficient fix being applied by the kernel. I'm not sure if Intel actually has any good fixes for meltdown in microcode. The in-kernel fix for that is fairly expensive, and if it could be fixed in microcode that would be a big savings (assuming the microcode didn't add a cost). My understanding is that most of the microcode patches are for spectre and modify the behavior of lfence to block vulnerable speculative execution. This still has some cost to it, but it is minimal. Without the microcode fix I imagine the vulnerabilities could still be fixed via retpolines and similar techniques, at a higher cost. I haven't checked recently but the last time I looked at it even my current Ryzen CPU doesn't have a microcode fix out yet for lfence. I haven't read up on what has changed in the last month or two, but the gist of it is that with spectre you have three options: 1. Ignore it. Some code is vulnerable. No performance cost. 2. Add a series of instructions to vulnerable code so that speculative execution is blocked on any processor. The code is no longer vulnerable, but those instructions can add some cost (not as bad as with meltdown). 3. If the CPU+microcode supports it, add a single lfence instruction to vulnerable code. This will address the vulnerability at a lower cost. In an ideal world we wouldn't need #2. That would not only make the fixes perform better, but it would also mean that compilers wouldn't have to generate code that figures out whether scenario 2 vs 3 applies AT RUNTIME and do the right thing. Now, if 95% of users fall into bucket 3 and 5% fall into bucket 2 you have an interesting situation. Will software developers take the time to ensure that scenario #2 is even covered, except for the most at-risk code (such as browser sandboxes)? Granted, I think in reality an awful lot of software will just fall into bucket #1 for the same reason that we STILL keep finding buffer overflows. That, and people will think of new situations where spectre applies that aren't presently known. I don't think we're at a point where a compiler can reliably determine whether a retpoline/lfence is actually needed. The last time I checked the GCC fixes needed the code to be tagged in some way to tell it to add the protection (when you think about it C doesn't even do bounds checks, let alone figure out when you're about to do a dangerous one). -- Rich
