https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table Reproducible: Always
amd not affected: https://lkml.org/lkml/2017/12/27/2
There are 2 different types of bugs: https://spectreattack.com "Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown." "In particular, we have verified Spectre on Intel, AMD, and ARM processors."
Relevant CVEs: [CVE-2017-5753] bounds check bypass [CVE-2017-5715] branch target injection [CVE-2017-5754] rogue data cache load Of these, the first two concern Spectre and the last concerns Meltdown.
External References: https://access.redhat.com/security/vulnerabilities/speculativeexecution https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://spectreattack.com/ https://meltdownattack.com
workaround as now https://github.com/torvalds/linux/commit/00a5ae218d57741088068799b810416ac249a9ce
Please consider that bug 643204 blocks the stabilization of kernel 4.14.11 for users of nvidia-drivers.
(In reply to Kilian from comment #6) > Please consider that bug 643204 blocks the stabilization of kernel 4.14.11 > for users of nvidia-drivers. The bugs have all already been weaponized to be simply usable from remote (javascript code in browsers in some cases). Putting the patched kernel in stable has just become very urgent.
I don't know if anyone has any ties to upstream, but currently KPTI cannot be enabled, as far as I know, for 32-bit x86 (4.14.12-gentoo). It almost seems that no one looks at x86 32-bit anymore and worries most about 64-bit. What can be done for 32-bit machines at this time? One thing I was also wondering about is whether 32-bit PAE also mitigates the issue because kernel and other process pages live on a different PAE address space, forcing cache flush when switching between user<->kernel space? I'm just guessing here and as there's no current PoC for 32-bit I don't have a way to test. Other than having a machine that I cannot enable PAE upon, I think this is an acceptable workaround if it indeed masks the problem.
(In reply to Ben from comment #8) > I don't know if anyone has any ties to upstream, but currently KPTI cannot > be enabled, as far as I know, for 32-bit x86 (4.14.12-gentoo). It almost > seems that no one looks at x86 32-bit anymore and worries most about 64-bit. > What can be done for 32-bit machines at this time? At least Patrik Voelkerding from Slackware and sone other guys does: https://www.linuxquestions.org/questions/slackware-14/strange-behavior-with-kernel-4-14-x-4175618207/
(In reply to Ben from comment #8) > I don't know if anyone has any ties to upstream, but currently KPTI cannot > be enabled, as far as I know, for 32-bit x86 (4.14.12-gentoo). It almost > seems that no one looks at x86 32-bit anymore and worries most about 64-bit. > What can be done for 32-bit machines at this time? Unfortunately, the only answer right now appears to be to become a grsecurity customer:- https://twitter.com/grsecurity/status/949499167700865024 https://twitter.com/grsecurity/status/949794658720337920 Otherwise, we can only hope that someone is inclined to work on porting the KPTI patches in the near term. If this does not happen, then it could be the end of IA-32 as a credible platform. I don't see what Gentoo could do in such a case other than to urge affected users to migrate to amd64 in the published GLSAs. In the meantime, I would humbly recommend that every practical effort is made to inform i686 arch users that upgrading gentoo-sources will not mitigate CVE-2017-5715.
My apologies. I meant, of course, to reference CVE-2017-5754 in the preceding comment. Additionally, I wish to present something else for consideration. The KAISER patchset was originally intended to harden the implementation of KASLR in the Linux kernel [1] [2]. It was hastily re-purposed to address Meltdown, and re-branded as KPTI in the process. Later, Thomas Lendacky submitted a patch that prevents KPTI from being activated by default for AMD processors - a patch that gentoo-sources is now carrying. AMD's pretext is that their processors are not affected by Meltdown. My concern over this situation is that it may put AMD processors at a disadvantage in lieu of the security issue that KAISER was originally intended to protect against. That is, KASLR may be unnecessarily weakened on AMD processors, by default. Indeed, the "Practical Timing Side Channel Attacks Against Kernel Space ASLR" whitepaper [3] specifically tested their attacks on AMD processors, which were found to be affected. Assuming that I'm correct, AMD users who enable both CONFIG_RANDOMIZE_BASE and CONFIG_PAGE_TABLE_ISOLATION will need to explicitly pass "pti=on" as a kernel option in order to harden KASLR, whereas Intel users will not. I realise that this is a less pressing concern then attending to Meltdown, but it struck me as being worthy of mention. [1] https://kernelnewbies.org/Linux_3.14#Kernel_address_space_randomization [2] https://lwn.net/Articles/738975/ [3] https://www.ieee-security.org/TC/SP2013/papers/4977a191.pdf
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5e03d21f4c2e4d15288156a6f79a13ba924a11e6 commit 5e03d21f4c2e4d15288156a6f79a13ba924a11e6 Author: kuzetsa <kuzetsa@gmail.com> AuthorDate: 2018-01-10 17:27:17 +0000 Commit: Göktürk Yüksek <gokturk@gentoo.org> CommitDate: 2018-01-10 20:57:04 +0000 sys-kernel/ck-sources: remove 4.13.x branch (EOL) corrupts bios, lack of meltdown / spectre fixes Bug: https://bugs.gentoo.org/642026 Bug: https://bugs.gentoo.org/643228 Package-Manager: Portage-2.3.13, Repoman-2.3.3 sys-kernel/ck-sources/Manifest | 7 --- sys-kernel/ck-sources/ck-sources-4.13.16-r1.ebuild | 64 ---------------------- 2 files changed, 71 deletions(-)}
can anyone make recommendations regarding replacement kernels? The only three Gentoo kernels not masked out on amd64 machines are 4.9.72, 4.9.49, and 4.4.87. All revisions >4.14.8 are masked out. It seems a little excessive dropping back 5 to 10 major revisions, and I am still not sure if they contain the proper patch sets. Thanks...
sorry. I just found recommendations here: https://wiki.gentoo.org/wiki/Project:Security/Vulnerabilities/Meltdown_and_Spectre I will use one of the recommended unstable kernels.
Please add a new stabilization request to the dependency for the coming GCC 7.3 with Retopline-Patches. https://www.phoronix.com/scan.php?page=news_item&px=GCC-7-Gets-Retpolines
Also, for anyone confused by the various techniques that have been devised to counter CVE-2017-5715 specifically, this post by David Woodhouse sheds considerable light on the matter, rather unlike Linus' widely publicised ranting up-thread: https://lkml.org/lkml/2018/1/22/598
At last, PTI support for x86 (32-bit) has landed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eac341194426ba7ead3444923b9eba491ae4feeb I have not personally verified but this should be in 4.18.
Unable to check for sanity: > no match for package: x11-drivers/nvidia-drivers-390.12
Unable to check for sanity: > dependent bug #644026 has errors
Resetting sanity check; package list is empty or all packages are done.
