[blfs-support] Speculative Store Bypass
zarniwhoop at ntlworld.com
Tue Jun 5 09:27:18 PDT 2018
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
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
before trying this, I would maybe not have bothered :)
And as to the intel firmware, according to
"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:
which makes me guess that the current microcode update is for
CVE-2018-3640 – Rogue System Register Read (RSRE) – also known as
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 ?
Keyboard not found, Press F1 to continue
More information about the blfs-support