[blfs-support] Speculative Store Bypass

[Bruce Dubbs]

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 understand your concerns about the speed issues but one comment about
using a tmpfs. I once did a full jhalfs build of LFS on a tmpfs. I
copied all the source tarballs to the ram disk and installed on the same
file system. The full build time was only 8% faster. My conclusion was
that disk IO for package builds is virtually negligible for our types of
workloads.

-- Bruce

[Michael Shell]

FWIW, when searching for more info on the SSB vulnerability, I found this:

https://www.tomshardware.com/news/researchers-discover-speculative-store-bypass-attack,37092.html


Tis some really bad news:

"But the hope remained that the manufacturers could solve the problem with
a few security updates. As it turns out, we can bury that hope. A total
of eight new security flaws in Intel CPUs have already been reported to
the manufacturer by several teams of researchers. For now, details on the
flaws are being kept secret. All eight are essentially caused by the same
design problem - you could say that they are Spectre Next Generation.
..
One of the Spectre-NG flaws simplifies attacks across system boundaries
to such an extent that we estimate the threat potential to be significantly
higher than with Spectre. Specifically, an attacker could launch exploit
code in a virtual machine (VM) and attack the host system from there - the
server of a cloud hoster, for example.
..
Overall, the Spectre-NG gaps show that Spectre and Meltdown were not a
one-off slip-up. It is not just a simple gap that could be plugged with a
few patches. Rather, it seems that for each fixed issue, two others crop
up. "



Mike Shell

[Ken Moffat]

On Mon, Jun 04, 2018 at 09:55:35PM +0100, Ken Moffat wrote:

At the moment, my typing is worse than usual, but apart from running

but that actually means soemthing like "only a program which uses
seccomp, for the new prctl for this, will be mitigated".

seccomp, OR the new prctl...

[Ken Moffat]

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.

Wrong!

For some reason, not yet understood, the firmware initrd I used for
the latest build on my haswell was apparently not up to date. Looks
as if what I put in the book for the example was similarly out of
date. I need to try to understand how that happened, before I
update that page.

When I looked to see if my SandyBridge has new microcode, that one
still had the previous late-load code in /lib/firmware, and it
matched the latest. So I extracted older and newer in different
directories and discovered that both had a releasenote (in the top
level). Diffing those, and then comparing the ucode md5sums, showed
two changes to microcode:

· 06-4f-01 (Xeon E5/E7, i7 Broadwell X, etc) has been removed - in
the releasenote it is labelled as "replaced by special release with
caveats", but obviously that is not in the current tarball

· 06-7a-01 changed (i.e. newer) - this is for Gemini Lake Pentium
and Celeron.

So, nothing for RSRE, nor for Speculative Store Bypass.

ĸen

[Ken Moffat]

Post by Ken Moffat

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.

Wrong!
For some reason, not yet understood, the firmware initrd I used for
the latest build on my haswell was apparently not up to date. Looks
as if what I put in the book for the example was similarly out of
date. I need to try to understand how that happened, before I
update that page.

In fact, the example in the book is fine. What happened is that I
reused a filesystem for my current build, and edited the grub.cfg
entry to refer to the new kernel - but left the old initrd instead
of replacing it with the new one. <sigh/>

ĸen