knweiss
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."
The problem isa) 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...
APFS in Detail
Apple File System
"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
"When the GPU is accessing this segment of memory, it should achieve 7/8th of its peak potential bandwidth, not far at all from what one would see with a fully enabled GM204. However, transfer rates for that last 512MB of memory will be much slower, at 1/8th the card's total potential."
http://techreport.com/review/27724/nvidia-the-geforce-gtx-97...