O Mon, Jun 04, 2018 at 09:55:35PM +0100, Ken Moffat wrote: > > I found the documentation hard to grok (too many negatives), but > apparently adding a bootarg of spec_store_bypass_disable=on does > turn it on all the time on suitable machines. > > The reason it is not normally enabled all the time is that it will > apparently slow things down a lot. I hope to do _some_ tests with > it set, but for the moemnt I don't have time. > I made a bit of time for testing, but some results were so strange that I cannot regard them as reliable. This is my 4-core ryzen, using -j4 (although a LOT of the time, even in the kernel modconfig, only one compile was actually running).
First I tried using the system with disable=on : often my terms (urxvt) were horribly unresponsive, although things seemed slightly less unreliable if I clicked on a second term (instead of tab to it) and typed slowly and distinctly. Ran some -j4 builds (without installs). Eventually tried the kernel's make allmodconfig but that ran out of space in /tmp. Rebooted to the default settings. Reran BLFS compiles of vim, boost, LLVM with clang and cfe. These were all in /tmp which is a tmpfs. For vim and boost, minor slowdowns with disable forced on, but only by half a second and 2 seconds which seems like normal variation. But with LLVM the build with disable forced on had taken 54% longer (110 minutes instead of 71 minutes). Then I rebooted back to disable=on, and did the builds on my SSD (which ought to be slower than tmpfs, I would have thought). kernel allmodconfig: over 121 minutes with disable=on, 82 minutes with the default (disable=on 47.6% slower). inkscape: 6.6% slower (all-but 7m58 vs 8m29) LLVM, again: this was the real shock, only 64m56 with disable=on and only 58m55 with the default, i.e. both faster than using tmpfs, but disable=on was still 10.2% slower. I stress that these are only ONE run of each build and I do not understand why the initial tmpfs disable=on llvm build was sooo slow. The system has 7.8GB of memory and 6GB of swap, I had firefox and falkon open, with several tabs in each. Summary: it looks as if mitigating everything will indeed be painful when compiling large packages. And normally unnecessary (which is fortunate where an intel CPU lacks preventative microcode). If I had read https://www.redhat.com/en/blog/speculative-store-bypass-explained-what-it-how-it-works before trying this, I would maybe not have bothered :) And as to the intel firmware, according to https://www.idgconnect.com/abstract/30532/what-speculative-store-bypass-spectre-variant-cpu-flaw "Fully mitigating the issue on Intel processors requires a mixture of software and CPU firmware updates, similar to Spectre. Intel says it’s already shipped microcode patches for Variant 4 to its hardware partners in beta form, and the company expects new motherboard BIOSes containing the fix to start rolling out “over the coming weeks.” But it seems like Intel thinks the browser fixes alone are protection enough, as the company says that the new firmware will ship with the Speculative Store Bypass mitigation disabled by default. You have to choose to manually enable it, which makes this fix feel a bit like public relations theater by Intel." I then found a link to intel: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html which makes me guess that the current microcode update is for CVE-2018-3640 – Rogue System Register Read (RSRE) – also known as Variant 3a. Summary: Do not use shared hardware, do not connect to the internet, do not pass go, do not collect 200 Flanian Pobble Beads. And ask yourself: Do I feel lucky ? ĸen -- Keyboard not found, Press F1 to continue -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
