Massive security hole in Xeons incoming?Official Meltdown/Spectre Discussion Thread

Page 66 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Aug 25, 2001
43,608
539
126
Wow. I stand corrected. I did not know it was possible to do...

I should buy more AMD shares...
The mov-only DOOM renders approximately one frame every 7 hours, so playing this version requires somewhat increased patience.
Well, that technique isn't exactly perfect, if you need computations in real-time.
 

HurleyBird

Golden Member
Apr 22, 2003
1,797
113
126
Is this for real? They are literally recommending not to use if statement. WTF.
It sounds more like this:

Code:
if (x < 0) x = 0;
is affected, rather than:

Code:
if (x < 0) y = 0;
At least that's the way I read it. Could be wrong. But even if I'm right, that's... still really bad.
 

Hitman928

Golden Member
Apr 15, 2012
1,761
194
136
Update from Toms. AMD confirms their CPUs are not effected by Spoiler. They also say that Cofee Lake and upcoming Intel CPUs are still vulnerable.

https://www.tomshardware.com/news/amd-processor-intel-spoiler-vulnerability,38841.html

Today AMD responded to news of the Spoiler vulnerability by confirming that its processors are not vulnerable to the exploit
The Spoiler exploit is present specifically within Intel's Core CPUs, which include the original Core 2 Duo CPUs all the way up to Intel's most recent Coffee Lake, Kaby Lake, and Skylake CPUs, as well as future Cascade Lake and Ice Lake products.
 

Tuna-Fish

Senior member
Mar 4, 2011
960
160
136
Is this for real? They are literally recommending not to use if statement. WTF.
Yes. And this advice will be permanent, btw. Spectre 1 is the only one of these new vulns that cannot be fixed without throwing away almost all of the performance of modern CPUs.

And the scope isn't if statements in general, it's specifically using control flow alone to guard data that is not supposed to be accessible. A good example of this would be the javascript engine in browsers doing a boundary check on array access. Traditionally, this might be something like:
Code:
int checked_get(size_t len, size_t index, int *array){
    if (index < len) return array[index];
    //if index > len, and that is rare in the program, the wrong value past the end of the array is speculatively returned.
    //since this was supposed to prevent a javascript program accessing things like cryptographical keys that can reside
    //in the same address space, this is a problem.

    //something else to deal with overflow
}
In the brave new world, this is not safe, and cannot be made safe by changes to cpus alone. Note that if statements are not the only flow control that is affected, things like Liskov substitution has also been successfully attacked. (That is, using multiple different subclasses of a superclass with different implementations, and leaking information by tricking the cpu to speculatively use the wrong subclass on the data of a different subclass.)

In the future, to protect data that is not supposed to be available, you need to use arithmetic or non-control-flow logic operations. Modifying our earlier example:

Code:
int checked_get(size_t len, size_t index, int *array){
    //make bitmask. works if len is a power of two
    size_t mask = len + len -1;
    if (index < len) return array[index & mask];
   // this way, if index is greater than len, it will speculatively return the wrong value but from inside the values you could access anyway.
   // no protection boundary is violated.

    //something else to deal with overflow
}
In principle, this was one of the transformations that was actually done to make javascript safe again.

In future, this might mean we will get things like new, fast boundary checking instructions that do the above (or something else safe) that can be used instead. Even a fast scalar max() implemented as a single-cycle instruction that depended on both values and outputted the larger one would do the trick. But the primary problem, that you can leak data from speculative contexts using the cache, and that control flow is no longer a safe way to enforce protection boundaries, cannot and will not be fixed, and affects all fast CPUs going forward.
 
Last edited:

moinmoin

Senior member
Jun 1, 2017
750
246
96
But the primary problem, that you can leak data from speculative contexts using the cache, and that control flow is no longer a safe way to enforce protection boundaries, cannot and will not be fixed, and affects all fast CPUs going forward.
You state this as something universally true. Is it? What's included as a "fast CPU" in this context, e.g. all modern ARM cores as well? Anything with any form of speculative execution?
 

Tuna-Fish

Senior member
Mar 4, 2011
960
160
136
You state this as something universally true. Is it? What's included as a "fast CPU" in this context, e.g. all modern ARM cores as well? Anything with any form of speculative execution?
Basically everything that combines branch prediction and a cache. This includes all the fast arm cores.
 

amd6502

Senior member
Apr 21, 2017
523
71
86

Tuna-Fish

Senior member
Mar 4, 2011
960
160
136
The existential crisis for modern CPUs (not just x86) continues. This latest one in the news is x86 specific though towards core series. I don't know anything about it. If anyone is up for it, it looks like some very deep reading that's going to take a chunk of time https://arxiv.org/pdf/1903.00446.pdf . https://www.guru3d.com/news-story/intel-procs-again-hit-by-massive-vulnerability-called-spoler.html
That one has been discussed on this thread since March 5th.
 

amd6502

Senior member
Apr 21, 2017
523
71
86
That one has been discussed on this thread since March 5th.
I'm new to this one; from browsing the article for 90 minutes but not really understanding most the details, it doesn't seem too bad in itself. It seems like it would take a very large amount of work to make practical real life use of it. The snooping on timings almost universal in the unpatched exploits. Webassembly seems like a bad idea that's going to be exploited very badly anyways.

My take is web apps will just have to be trusted to do a good job on security, and sandbox javascript as best as they can with timer functions that output with increasing noise for scripts that make excessive frequent calls.
 

UsandThem

Super Moderator
Super Moderator
May 4, 2000
10,719
496
136
Yet another variation / vulnerability:

https://www.zdnet.com/article/intel-cpus-impacted-by-new-zombieload-side-channel-attack/
Today, an international team of academics -- including some of the people involved in the original Meltdown and Spectre research -- along with security researchers from Bitdefender have disclosed a new attack impacting the speculative execution process.

This one is what researchers have named a Microarchitectural Data Sampling (MDS) attack, and targets a CPU's microarchitectural data structures, such as the load, store, and line fill buffers, which the CPU uses for fast reads/writes of data being processed inside the CPU. These are smaller-sized caches that are used alongside the main CPU cache.
 

Hitman928

Golden Member
Apr 15, 2012
1,761
194
136
Looks like the new architecture changes cover this new attack. Older CPUs have received / will receive microcode updates.

Furthermore, newer processors aren't impacted, as they already include protections against speculative execution attacks --such as the MDS attacks-- since last year when Meltdown and Spectre first hit, and Intel modified the way its CPU's worked.
Edit: I'm just quoting the zdnet article. If you disagree with it, take it up with them, not me, lol.
 
Last edited:

amdfan111

Junior Member
Feb 9, 2018
16
11
16
In a call with TechCrunch, Intel said the microcode updates, like previous patches, would have an impact on processor performance. An Intel spokesperson told TechCrunch that most patched consumer devices could take a 3 percent performance hit at worst, and as much as 9 percent in a datacenter environment. But, the spokesperson said, it was unlikely to be noticeable in most scenarious.
Yet again, AMD not affected, but sure, 9% performance decrease will surely not be "noticeable." Ryzen was tied with Intel at launch, and now between Meltdown, Spectre, L1TF, and this new Zombie(!) exploit, Ryzen is 30% higher IPC than Coffee or whatever Lake.
 

Hitman928

Golden Member
Apr 15, 2012
1,761
194
136
Feb 4, 2009
20,070
1,081
126

Deigarth

Junior Member
Mar 13, 2017
5
7
51
Apr 27, 2000
11,512
844
126
Looks like the new architecture changes cover this new attack. Older CPUs have received / will receive microcode updates.
Just another reason for people to get off those Skylake-SP systems. It'll be interesting to see what they buy as replacements.

Edit: I'm just quoting the zdnet article. If you disagree with it, take it up with them, not me, lol.
I know, right? People are so touchy sometimes.
 

Deigarth

Junior Member
Mar 13, 2017
5
7
51
It also looks like Intel abused the process of responsible disclosure for economic reasons. Wasting security researchers time, trying to "gift" them money instead of a proper bug bounty and also trying to delay release to the public. It think it reflects badly on them, security researchers will probably not put up with that again.

Wired:
That's hardly the kind of money paid out for trivial issues, he points out. But he also says that Intel at one point offered VUSec only a $40,000 bug bounty, accompanied by a $80,000 "gift"—which Giuffrida saw as an attempt to reduce the bounty amount cited publicly and thus the perceived severity of the MDS flaws. VUSec refused the offer of more total money in favor of a bounty that better reflected the severity of its findings, and it threatened to opt out of a bug bounty in protest. Intel changed its offer to the full $100,000.
Translated from the NL interview:
The VU tried to force the manufacturer to come out faster. Eventually the VU forced Intel to come out in May - otherwise the university would publish the details itself. "If it were up to Intel, they would have wanted to wait another six months," says Bos.
Sources:
https://www.wired.com/story/intel-mds-attack-speculative-execution-buffer/
https://www.nrc.nl/nieuws/2019/05/14/hackers-mikken-op-het-intel-hart-a3960208

Edit:
 
Last edited:
Looks like the new architecture changes cover this new attack. Older CPUs have received / will receive microcode updates.

Edit: I'm just quoting the zdnet article. If you disagree with it, take it up with them, not me, lol.
It seems to get only worse instead: https://mdsattacks.com/

Screenshot_20190515-095352_Firefox.jpg
 
Last edited:

TheGiant

Senior member
Jun 12, 2017
365
47
76
ok, so we get another patches and whatever.....

Intel has like 90+% of CPUs used in the computer world, it is logical the researchers focused on them

any info if researchers plan to exploit EPYCs, power, apple axx etc CPUs?

they work by logical algoritms all, so can be broken...
 

jpiniero

Diamond Member
Oct 1, 2010
6,327
226
126
I wouldn't be surprised if the bribing they are talking about was so that they can move the remaining stock of Skylake-SP, assuming Cascade Lake is unaffected.

It seems to get only worse instead: https://mdsattacks.com/
That's the confusing thing about this. Are they talking about the microcode changes Intel's done so far or the hardware fixes?
 
Apr 27, 2000
11,512
844
126
It seems to get only worse instead:
Ugh. More vulnerable? Is there any more data on that?

That's the confusing thing about this. Are they talking about the microcode changes Intel's done so far or the hardware fixes?
The main difference between 8th and 9th gen chips is the hardware mitigations (wrt Spectre/Meltdown). So the hardware mitigations may introduce new flaws.
 


ASK THE COMMUNITY