Last week, a series of critical vulnerabilities called Spectre and Meltdown were announced. Because of the nature of these issues, the solutions are complex and requires fixing delicate code. The fixes for Meltdown are mostly underway. The Meltdown fix for x86 is KPTI. KPTI has been merged into the mainline Linux tree and many stable trees, including the ones Fedora uses. Fixes for other arches are close to being done and should be available soon. Fixing Spectre is more difficult and requires fixes across multiple areas.
Similarly to Meltdown, Spectre takes advantage of speculation done by CPUs. Part of the fix for Spectre is disallowing the CPU to speculate in particular vulnerable sequences. One solution developed by Google and others is to introduce “retpolines” which do not allow speculation. A sequence of code that might allow dangerous speculation is replaced with a “retpoline” which will not speculate. The difficult part of this solution is that the compiler needs to be aware of where to place a retpoline. This means a complete solution involves the compiler as well.
The first part of the work necessary for retpoline is now done. This should be completely merged in the next few days and available in Fedora stable releases shortly. These patches by themselves do provide a degree of protection against Spectre attacks but more work is needed to be a complete solution. The compiler support to provide further protection are still under review by upstream developers. Support for other arches is ongoing.
An alternative to the retpoline patches involves exposing some hardware features to more tightly control speculation. Some CPUs have a feature called Indirect Branch Restricted Speculation (IBRS). When this feature is enabled, userspace programs are further restricted in how they are able to speculatively execute instructions. Fully supporting this feature requires microcode updates, some of which are available now with others available shortly. IBRS provides a more complete solution without the need for compiler support but at a higher performance cost. The IBRS patches are still under review and should be merged eventually but will not be available in time for 4.15. When the IBRS patches are available, we will be backporting them to Fedora stable branches.
Both IBRS and retpoline cover the “variant 2” version of Spectre. The “variant 1” version of Spectre doesn’t have a solution with a quick and catchy name. The solution for variant 1 involves scanning the code for sequences that may be problematic. The method for scanning the code tends to produce many false positives (sequences that are not actually vulnerable) so upstream developers are trying to narrow down which parts of the code actually need fixing. Fixes for sequences which are known to be vulnerable have been merged.
Although Spectre is an important security issue, just as important is careful review of fixes to make sure the solution is maintainable. Rushing a fix could cause more problems in the future. The Fedora team is continually monitoring Spectre fixes to bring them to you when they are ready.
Costa A.
Let’s be honest here. There is a published paper since 1995 from some security experts from IEEE mentioning that speculative execution of the CPU is a security flaw.
Everybody knew, they just overlooked the potential danger over the benefits of faster calculations by the chips.
JohnHentle
Speculative execution on its own is not the security breaking issue here. Provide the paper you referenced, please.
Costa A.
I think that’s the one, except i’m missing something:
https://www.csee.umbc.edu/~younis/Publications/IEEE_TSE_2/Younis_TSE_2.pdf
Cliff Wells
There’s no discussion of security in that article, only a discussion of the impact of speculative execution on real-time tasks.
john galt
waste of ink, looking for info on what i can do about it, bottom line after all these words is …no fix yet, work still ongoing
Antonio Augusto Alves Jr
Hi Laura, I can imagine you are under a huge pressure managing these things. Please, keep calm and dont open hand of proper code review and testing.
People from other popular distro allowed buggy patches to be pushed ahead… and the jeopardy got only worst!
Cheers
A.A.
abedalbaaset
fedora is amazing thanks for provided it
Beslo
I’m glad to hear it’s coming along, as Fedora is my personal choice and the obvious choice for server workloads.
Sudip Chatterjee
I commend Costa A. for spilling out the truth. Both of these flaws are well-known for decades. But mercenary instincts overthrew common engineering practice. This is a very careless incident which fortunately got wide attention of the media. Many such incidents go unreported and cause irreparable harm to our day-to-day computing. And that happens without our awareness. Concerted effort is needed from organizations as well as the general public to address such issues. Awareness of security, privacy, and overall aspects of computing must be percolated to every nook-and-corner of society.
I also commend Fedora’s approach towards solving the issue. The folks at Canonical got it all messed up. A sensible way is developing the right patch which may take some time, rather than rushing a patch and then spending time patching that patch!
Arnold Sutter
To add to Costa’s comment above, how come the plan how to correct the vulnerabilities including the correction code is not already IN the updated Linux distro’s, since this issue is internally known (by Google and others, including OS maintainers) for 6 months already?
Neil Darlow
These vulnerabilities are unprecedented and it is pleasing to see that already some mitigation for Meltdown has gone into the Linux kernel with microcode updates to follow.
Regarding the more complex to address Spectre vulnerability, which requires support from compilers to generate immune code, this will require a significant OS update to implement.
Is the fedora project preparing a plan to (effectively) respin the supported distributions using the modified compilers? It would be a great pity for wide-ranging fixes to be made available but users having to wait for the next scheduled release to receive the benefit.
One thing’s for sure. The black hats will be working every bit as fast to exploit these vulnerabilities as the OS vendors are to close the holes. I just hope the result is in the end-users favour.