Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 643352 - sys-kernel/gentoo-sources: Meltdown mitigation (KPTI patch set)
Summary: sys-kernel/gentoo-sources: Meltdown mitigation (KPTI patch set)
Status: IN_PROGRESS
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Kernel (show other bugs)
Hardware: All Linux
: Normal major with 2 votes (vote)
Assignee: Gentoo Kernel Security
URL:
Whiteboard: A2 [upstream/ebuild]
Keywords:
: 643338 643360 (view as bug list)
Depends on:
Blocks: CVE-2017-5753 CVE-2017-5715 CVE-2017-5754
  Show dependency tree
 
Reported: 2018-01-04 01:35 UTC by GLSAMaker/CVETool Bot
Modified: 2018-10-01 16:30 UTC (History)
51 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description GLSAMaker/CVETool Bot gentoo-dev 2018-01-04 01:35:21 UTC
Incoming details.
Comment 1 Thomas Deutschmann gentoo-dev Security 2018-01-04 01:39:02 UTC
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.
Comment 2 Brian Evans Gentoo Infrastructure gentoo-dev 2018-01-04 13:53:13 UTC
*** Bug 643360 has been marked as a duplicate of this bug. ***
Comment 3 Kerin Millar 2018-01-04 15:33:11 UTC
*** Bug 643338 has been marked as a duplicate of this bug. ***
Comment 4 Alice Ferrazzi Gentoo Infrastructure gentoo-dev 2018-01-06 15:07:56 UTC
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 )
Comment 5 pva 2018-01-07 22:27:06 UTC
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.(?)
Comment 6 Oliver Freyermuth 2018-01-07 23:47:30 UTC
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.
Comment 7 pva 2018-01-08 17:57:55 UTC
(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.
Comment 8 Yury German Gentoo Infrastructure gentoo-dev Security 2018-01-08 19:10:55 UTC
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.
Comment 9 Kerin Millar 2018-01-13 09:39:51 UTC
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.