I am being nice to Intel… they have switched to a whole lot of them too and finger pointing without admitting they have any issue whatsoever. It’s disgusting as they have failed to admit any sort of problem.
listening to a marketing gimmick
[4] This PoC won’t work on CPUs with SMAP support; however, that is not a fundamental limitation.
That being in regard to Variant 1 & 2
AMD states that its Ryzen processors have “an
artificial intelligence neural network that learns to predict
what future pathway an application will take based
on past runs” [3, 5], implying even more complex speculative
behavior. As a result, while the stop-gap countermeasures
described in the previous section may help
limit practical exploits in the short term, there is currently
no way to know whether a particular code construction
is, or is not, safe across today’s processors – much less
future designs.
1 Like
They’re worried that if they do, they’ll lose the server market.
Fixing this problem won’t be easy for future cpu revisions. They probably think they can brush it off and act like it’s not an issue.
Well, the CEO clearly does not think that. 
2 Likes
Note that this paper is by now old, and a lot of further work & research has been done in cooperation with involved parties and businesses.
1.3 Targeted Hardware and Current Status
Hardware. We have empirically verified the vulnerability
of several Intel processors to Spectre attacks, including
Ivy Bridge, Haswell and Skylake based processors.
We have also verified the attack’s applicability
to AMD Ryzen CPUs.
4.1 Discussion
Experiments were performed on multiple x86 processor
architectures, including Intel Ivy Bridge (i7-3630QM),
Intel Haswell (i7-4650U), Intel Skylake (unspecified
Xeon on Google Cloud), and AMD Ryzen. The Spectre
vulnerability was observed on all of these CPUs. Similar
results were observed on both 32- and 64-bit modes, and
both Linux and Windows.
6.4 Limitations on ARM and AMD
We also tried to reproduce the Meltdown bug on several
ARM and AMD CPUs. However, we did not manage
to successfully leak kernel memory with the attack described
in Section 5, neither on ARM nor on AMD. The
reasons for this can be manifold. First of all, our implementation
might simply be too slow and a more optimized
version might succeed. For instance, a more shallow
out-of-order execution pipeline could tip the race
condition towards against the data leakage. Similarly,
if the processor lacks certain features, e.g., no re-order
buffer, our current implementation might not be able to
leak data. However, for both ARM and AMD, the toy
example as described in Section 3 works reliably, indicating
that out-of-order execution generally occurs and
instructions past illegal memory accesses are also performed.
3 Likes
2 Likes
They stand to lose even more by glossing over and saying they don’t have a problem and that if they do have a problem well its the other guys too.
Not saying they don’t.
You know when you were a kid and your mom asked if you took from the cookie jar? You had crumbs on your shirt, but you still said “no.” That’s what Intel’s been doing for the past day or so.
All I can say is that speculative execution and branch prediction will become a lot more interesting with the next CPU revisions. 
AMD & Intel may well push back chip releases that haven’t yet been fabricated.
1 Like
Do you think we’re too late for them to push Zen+?
Makes me wonder how many people in purchasing decisions will see this deflecting and refusal to admit a problem as an influencer in the decision. I for one know I want a company to tackle a issue headon, don’t give me excuses… give me fixes and don’t tell me the competition does it too. If I hear that I just might look at the competition… not because they are there, but simply because throwing shade is your tactic you must be scared of something.
It’s definitely sold me. I’m never buying Intel again if I can help it. (and I handle hardware purchases for my company’s datacenters)
1 Like
I can’t say.
But this is why KPTI isn’t applied for AMD CPU’s
1.4 Meltdown
Meltdown [27] is a related microarchitectural attack
which exploits out-of-order execution in order to leak
the target’s physical memory. Meltdown is distinct from
Spectre Attacks in two main ways. First, unlike Spectre,
Meltdown does not use branch prediction for achieving
speculative execution. Instead, it relies on the observation
that when an instruction causes a trap, following instructions
that were executed out-of-order are aborted.
Second, Meltdown exploits a privilege escalation vulnerability
specific to Intel processors, due to which speculatively
executed instructions can bypass memory protection.
Combining these issues, Meltdown accesses kernel
memory from user space. This access causes a trap, but
before the trap is issued, the code that follows the access
leaks the contents of the accessed memory through
a cache channel.
Unlike Meltdown, the Spectre attack works on nonIntel
processors, including AMD and ARM processors.
Furthermore, the KAISER patch [19], which has been
widely applied as a mitigation to the Meltdown attack,
does not protect against Spectre.
Spectre is currently the scary one for AMD users. And it has mitigations that will be incoming soon.
For Intel, it’s everything that’s affected.
3 Likes
Off topic. But It’s going to get harder and harder to sneak backdoors into hardware now the internet age is upon us. Every time they do within 6 months to a year it has to be patched out again when someone finds the hole.
In hardware?
No. It’s just as easy.
After all, we do have the Management Engine.
It’s not a backdoor bug, it’s a feature! 
4 Likes
But that’s an example where some companies are opting to turn it off for that very reason (see System76)
Yeah, but on a lot of systems, it’s not ready.
The problem is the level of risk associated with doing this.
If you break it, you need to have a dump of the nvmem that you can use a jtag tool to fix your motherboard with.