All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
New very serious intel processors vulnerability [CacheOut]
"cacheout", I quote,
a new speculative execution attack that is capable of leaking data from Intel CPUs across many security boundaries. We show that despite Intel's attempts to address previous generations of speculative execution attacks, CPUs are still vulnerable, allowing attackers to exploit these vulnerabilities to leak sensitive data.
Moreover, unlike previous MDS issues, we show in our work how an attacker can exploit the CPU's caching mechanisms to select what data to leak, as opposed to waiting for the data to be available.
(emphasis mine)
Which processors (short version)? All intel processor up to and including Q4 2018 (which translates to "most systems used in the low end hosting market".
AMD too? Nope.
Intel only (because only intel has TSX Asynchronous Abort (TAA))
Mitigation avaliable? Yes, it seems so but I don't know yet about the performance penalty.
main link: https://cacheoutattack.com/
List of affected intel processors: https://software.intel.com/security-software-guidance/insights/processors-affected-l1d-eviction-sampling
Comments
Probably worth the effort to switch to AMD servers now. Just hope providers won't price gouge lol
Definitely worth the effort! Ryzen, EPYC, Athlon XP 1800, all very good on plow and doesn't leak, unlike soviet-era potassium reactors.
My Ryzen and EPYC test data show both are superb stuff your data will get high on. Time to switch before stocks run out.
I like my data high, and private..
A propos "top potassium", for those of you who want to squeeze out the last drop of Zen performance and as it seems that only very few know about it: AMD has created a Zen specific C/C++ compiler based on clang v.9. It's called "AOCC" - link -> https://developer.amd.com/amd-aocc/
AOCC evidently applies AMD's deep knowledge of their Zen processors (both Zen 1 and Zen 2) in their clang version.
time to abandan all intels!
Extraordinary potassium discovery there Randy Bobandy
IIRC, last https://www.phoronix.com/ benchmarks show AMD AOCC compiler still behind GCC 9+ for AMD cpus or only a few pts ahead. Still needs work on AOCC side right now.
Yes and no. GCC (still) is generally somewhat faster than Clang but if one uses AOCC to compile specifically for Zen then the result is faster but of course runs only on the Zen (1 or 2) processors targeted. That however is generally not desirable because one usually wants ones code to run on all 64 bit x86 processors.
But, and that's what I addressed, if one does know that some code will run on say a Zen 2 processor, AOCC can do some magic. Example: I use a static analyzer that eats a massive amount of cycles and I know that I'm running it on a Zen processor so it made sense for me to create a Zen specific executable.
Btw, one should be careful with Phoronix statements re compilers because I've seen them multiple times careless (or clueless?) in that area.
Btw 2, usually one doesn't choose clang vs gcc based on performance anyway but based either on certain pragmatic criteria like e.g. sanitizer preferences or based on some specific needed detail like for example target handling.
FWIW I myself usually prefer/use gcc but sometimes clang just is the better tool. Also note that quite a few non-compiler tools are clang/llvm based (which means that as a developer you usually have clang on your system anyway).
Btw based on what I'm hearing to add to intels many problems they also seem to have a production bottleneck. This might add some added push for large customers towards AMD. It's obviously more attractive than building systems around seriously vulnerable processors that can't be purchased anyway.
Looks like, its a big thank you from Intel, to people who recently bought new Intel cpu's.
Good for us, we had considered a lot in the past few weeks whether we would continue to use Intel Gold or AMD Epyc. We recently made a good decision and ordered new systems with AMD Epyc processors
@Avoro said:
Have been happy with your gold, but now it's time to be happier.
We are also migrating existing customers to the new AMD Epycs ;-)
Serious as in "right now my neighbour can read the password I'm typing on my notebook" or as in "a specially crafted/malicious software installed on an already breached fucked-up system can read memory bits of random info where it should not"?
This is why team Red is PREM
(a) > 99% of systems can be breached. But this is mostly about (somehow shared) servers.
(b) Quote from the paper
Sounds serious enough to me. Anyway much graver than Spectre, Meltdown, etc.
About the only good news is that it seems likely that microcode updates plus changes in the kernel can provide at least some degree of mitigation.
As the major part of mitigation is to (frequently) flush the L1D cache and considering that reloading it from L2, L3, or RAM is very expensive in terms of time, the price to pay for restoring security (well, as much security as one can have on an intel processor anyway ...) is to be expected to be noticeable.
Most important though IMO is something else: One vulnerability may be bad luck, but the meanwhile remarkable series of "bad luck" for intel as well as the fact that the search for more is still at the beginning strongly suggests that this is not the last and likely not even the worst vulnerability and more ugly stuff is to come.
My suspicion is that we are about to pay the price for the way which intel chose to respond to the ever present (rather mindless) demands for ever more performance (so that ever worse and crappier bloated software monstrosities could run "fast").
We should understand that (especially large) companies are usually driven by shareholder value (read: profit) and tend to choose the simplest way to achieve that. In a monopoly position and a market that didn't care about security and quality for many many years but only about ever more performance the day when the "invoice" for careless engineering ruled by sales and marketing just had to come - and since a while it has arrived and intel is bleeding (and so are we, intels customers).
Btw and FWIW, I don't think that AMD is the big winner in this in the long run. I think the big winner will be a new architecture, probably Risc-V, that doesn't need to be backwards compatible (read: carry lots and lots of burden with it).
TL;DR but if I understand correctly I should just run "shutdown now" on all my Intel-based dedis otherwise I'm fucked.
Take advantage of our switcher special
No, but maybe on any VPSs and VMs.
So, "very" serious but only for some use cases, and with... what worst outcome for the average joe? SSH password stealing? Reading my /etc/fstab? Deciphering my TLS connections to deb.debian.org? I mean, c'm'on, the NSA can already to that with their quantum crypto breakers, even if you use AMD CPUs.
reaches for tinfoil hat
@2Shot, the issue is not how it could harm you directly.
The issue is that a fix might potentially reduce performance of Intel CPU. There have been like 3 or 4 fixes for CPU bugs already which has an impact for systems that have fixes applied.
Can't cite a link to a source but I recall reading a general loss of 3 ~ 5% of performance and a large reduction of performance on some specific tasks relating to bugs.
What this means is dat the end is nigh and you should worship me.
Yikes Intel. AMD ftw, best value out there.
Well having your SSH password stolen is quite bad.
Maybe I didn't make it clear enough but there is a decisive difference to Spectre and the like: with CacheOut it isn't a mix of lottery and patience but more like in a restaurant; just pick something from the menu.
An L1D set is typically 64 bytes (512 bits) which is good enough for most secrets and keys. Considering that good developers try to keep confidential data (like keys) in L1D, because it's the closest storage area of sufficient size to the core (and on the same die) CacheOut means that almost all crypto is considerably less secure on systems that run on a VM or otherwise shared.
But it also means that rather sooner than later you'll see malware using CacheOut - and then the number of potential targets multiplies and might well include your desktop.
Another way of seeing it is this: We developers went out of our way to avoid side channel attacks ... and now with CacheOut that's worthless because, to put it into a picture, a fence that was 5 feet high until now suddenly is gone and replace by a white line and a sign saying "private property. Please do not enter".
While there are good news too, at least looking superficially, in that mitigation seems possible and even relatively cheap (in terms of performance cost), the bad new is that that mitigation won't help on somehow infected desktops or servers, and even worse, the series of intel vulnerabilities very strongly suggests that more is to come and some of it even worse than CacheOut.
As for "the NSA can already to that" I disagree because I see no reason to assume that the NSA (or anyone) already has sufficiently wide (# of bits) quantum computers.
With all of the mitigations in place, what's the real performance of an Intel processor to a comparably priced AMD?
"comparably priced AMD?"?
But if you mean a $1000 intel processor vs a $1000 AMD processor the difference is already (without any mitigation) so large that the mitigation cost is insignificant.
If you mean an intel processor and an AMD processor of roughly the same performance yesterday, not much will change from what I can see so far. The mitigation seems to be largely based on flushing or emptying the L1D at every context switch (which happens relatively "rarely" like every million cycles or so) meaning it's cheap.
This will cause market to flood with more old intel's sold for cheap. Don't expect many low end providers to change when getting tons of cheaper intel servers (ie, the ones already using 8+ year old CPU's).
Do we need to create tickets for migration or migration will be automatic?
I have some Ryzens to sell you all ;-)
Definitely not from 1999.