Incoming details.
See tracker bugs for details. We will use this bug to track status of sys-kernel/gentoo-sources (i.e. which ebuilds contain the patch set) and stabilization.
*** Bug 643360 has been marked as a duplicate of this bug. ***
*** Bug 643338 has been marked as a duplicate of this bug. ***
The gentoo-sources with the KPTI-patch are as now: 4.14.11 ( incomplete patchset enabling KPTI for all CPU architecture ) 4.14.11-r1 ( Reducted patchset KPTI only for intel x86 architecture but missing dumpstack and Define cpu_tss_rw in same section as declaration ) 4.14.11-r2 ( Complete KPTI patchset ) 4.14.12 ( Complete KPTI patchset+ amd support for fam17h microcode loading ) 4.9.75 ( Complete KPTI patchset+ amd support for fam17h microcode loading ) 4.4.110 ( Complete KPTI patchset+ amd support for fam17h microcode loading )
Meltdown is CVE-2017-5754. Why does KPTI blocks CVE-2017-5753 and CVE-2017-5715? I think this bug should not block spectre. For CVE-2017-5753 and CVE-2017-5715 on kernel side Gentoo (probably) needs some fencing, like suse did: https://kernel.opensuse.org/cgit/kernel-source/log/?h=SLE12-SP3&id=13cbca871c3fe1184250f54ef95452a7296c4200&qt=grep&q=speculative but I'd better wait for linus kernel solution. May be it'll be enough to fix toolchain (https://support.google.com/faqs/answer/7625886) and rebuid kernel.(?)
This bug is certainly the wrong place for discussion, so I'm sorry for replying at all, but there are two approaches for spectre which are indeed unrelated to meltdown, so I presume the bug title is wrong. To prevent misinformation, I'm summarizing the spectre approaches (which are orthogonal in a way): 1) Usage of IBPB and IBRS, requires new microcode (released as intel-microcode-20171117_p20171215-r1) and kernel patches. RHEL already has these patches in, but I believe not even all of them have been publicly posted, and there has been a lot of discussion and changes on the public patchsets been going on on LKML. 2) retpoline. Since IBPB and IBRS lead to abysmal performance loss on pre-skylake systems (c.f. https://lkml.org/lkml/2018/1/4/708 ), retpoline uses special instructions to work around speculative execution. For the kernel, patches to kernel assembly + patches to toolchain compiling it are required. AFAICT, no distro uses that as of yet, and the patches are heavily worked on on LKML. For Skylake, retpoline is insufficient since speculative execution may also happen for returns, so approach 1 is required (and performance loss is less abysmal on this hw). In the end, probably (1) could be used initially (as RHEL does) but potentially both will be necessary to prevent the heavy performance loss on pre-skylake hardware.
(In reply to Oliver Freyermuth from comment #6) > This bug is certainly the wrong place for discussion Oliver, why? What is the right place then? I would like to see Gentoo discussion of this issue but I'm not sure where it happens and it looks like bugzilla is the right place. > but there are two approaches for spectre which are indeed > unrelated to meltdown, so I presume the bug title is wrong. Since KPTI is already merged in Linus's sources it's good idea to separate KPTI patchset from ibpb/ibrs kernel patches and related microcode updates. > 1) Usage of IBPB and IBRS, requires new microcode (released as > intel-microcode-20171117_p20171215-r1) and kernel patches. > RHEL already has these patches in[...] Suse already did similar thing but with different name for option and without debugfs support: https://kernel.opensuse.org/cgit/kernel-source/commit/?h=SLE12-SP3&id=13cbca871c3fe1184250f54ef95452a7296c4200 To avoid further confusion it's better to waited for upstream (Linus) decision on this patchse. > 2) retpoline. Ok, I see. Thank you for lwn link.
Please see the blockers. They are not actual bugs but are tracker bugs. Tracker bugs are there to track multiple bugs that are associated with a particular CVE so that a CVE can be assigned to the tracker. Please note these bugs will not be closed for some time as there are multiple stages that the kernel, microcode, etc will have to go through.
After reading this post by Andrew Lutomirski, I have given up what little hope I had left of the the 4.4 and 4.9 series ever having a KAISER/PTI implementation that is production-fit: https://news.ycombinator.com/item?id=16087736 Andrew goes as far as to say that people should "put pressure on your organization or suppliers to update to 4.14" - hardly surprising given the other remarks in this post. Therefore, I would encourage the Gentoo kernel team to take this into consideration, especially as we are one of the distros that is "using an old kernel", as he puts it.
Resolved since >=sys-kernel/gentoo-sources-4.4.111-r1 >=sys-kernel/gentoo-sources-4.9.76-r1 >=sys-kernel/gentoo-sources-4.14.14
