I can’t believe you’re the only one mentioning this.
164 karma · joined January 3, 2010
Also, take a look at their user forums: They are full of bug reports with hundreds of users having the same problems - and nothing happens. I really wish they would react much better with official acknowledgments, references to open bugs, workarounds, etc. It is depressing how much collective time is wasted.
The source code is available on GitHub.
I'm mentioning this because (at least to my understanding) in Spectre variant 2 the entire address space of the victim process can be used to find the "gadget" i.e. an usable target for the indirect branch. This means that making only your input validation code "spectre-free" is not good enough for variant 2. (This is why e.g. OpenSSH recently started using the (Spectre variant 2!) retpoline compiler flags of GCC/LLVM if available. See this thread for details: https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-Fe...)
"When performing Diffie-Hellman Group Exchange, sshd(8)
first estimates the size of the modulus required to
produce enough Diffie-Hellman output to sufficiently
key the selected symmetric cipher. sshd(8) then randomly
selects a modulus from /etc/ssh/moduli that best meets
the size requirement."
a) OS distributions ship pre-computed moduli in the /etc/ssh/moduli file. I.e. most users don't change these moduli. This facilitates pre-computation attacks.
b) These moduli are often too short (<2048 bit).
You can create your own moduli with ssh-keygen (see the "MODULI GENERATION" section in the ssh-keygen manpage).
FWIW: Here's my open bug for RHEL7 where I try to convince Red Hat to improve the situation (including more details and references):
https://begriffs.com/posts/2016-11-05-advanced-intro-gnupg.h...
"Sampling profilers, the most common performance debugging tool, are notoriously bad at debugging problems caused by tail latency because they aggregate events into averages. But tail latency is, by definition, not average."
Quote:
On Haswell, one AVX instruction on one core forced all cores on the same socket to slow down their clockspeed by around 2 to 4 speed bins (-200,-400 MHz) for at least 1 ms, as AVX has a higher power requirement that reduces how much a CPU can turbo. On Broadwell, only the cores that run AVX code will be reducing their clockspeed, allowing the other cores to run at higher speeds.
The latter should be a signal for the distribution to upgrade to a newer and supported upstream version instead of (halfheartedly) trying to support the software themselves.
[0] - http://www.anandtech.com/show/9794/a-few-notes-on-intels-kni...
IPFS comes to mind.
This is the "Persistent Memory" device class. See e.g. this article for a nice summary of the status quo: https://lwn.net/Articles/636096/
Actually, I did and it was a top-priority for me.
First 3.5 GB : 196 GB/s == 7/8 of 224 GB/s
Last 0.5 GB : 28 GB/s == 1/8 of 224 GB/s
In other words: "insecure" or "unstable" - choose one.
I'm all for upgrading to Yosemite, but this is a problem.
The dual-core CPU you are looking for is called the "Pentium Anniversary Edition: Intel Pentium G3258" and was released in July.
-march=nehalem, westmere, sandybridge, ivybridge, haswell,
bonnell, broadwell, silvermont
-mtune=intel can now be used to generate code running well
on the most current Intel processors, which are Haswell
and Silvermont for GCC 4.9.