Hacker News Reader

Comment by Grangar | Hacker News Reader

At risk of missing sarcasm, a large reason all these vulnerabilities in Intel are found is their market share. Same as when OSX was considered "unhackable" - it just wasn't worth the effort. AMD is likely just as bad, but it's not uncovered (yet).

Supporting the underdog is a good idea nonetheless, but not for this reason per se.

View on HN

Or it is the other way around. Intel had cut corners to be able to make the fastest processors, and that is how they got their marketshare. They have been called out on it in the last two years and updates have made their processors slower. Also AMD improved massively with Zen.

More like this, intel has cut a lot of corners for a long time in their x86 processors, mostly to have better performance, which ended up with all these vulnerabilites we keep hearing about every couple of months. They're just now suffering the consequences of all the shady things they've done to try and establish a monopoly in the CPU market

A more generous interpretation: Intel made decisions that favored actual measurable performance today at the expensive of theoretically known vulnerabilities that might be exploited in some hypothetical future. They gave the market what the market demanded at a cost they tolerated.

And even now, after said theoretical vulnerabilities have been reified, there is very little cause to be concerned about the vulnerabilities under discussion unless you host code for other people as a business model (or use such a service). Otherwise your biggest concern is a web browser that already has a whole host of actual and theoretical vulnerabilities of its own.

> They gave the market what the market demanded at a cost they tolerated.

This suggests a level of informed consent that I don't think existed. It implies that "the market" (who?) knew of, understood, and agreed to the risks.

And anyway, "the market" does a poor job of representing some of its stakeholders, notably the disorganized group known as users, and immediate competitive advantage may be the only metric driving decision-making.

Intel made decisions that favored the actual indicators people were looking at with a hidden cost on things people weren't aware of. They got the market exactly what the market demanded while deceiving that market by applying known bad practices. There is a huge difference in impact from saving money by using lead-based paint, but it's the same kind of decision.

> unless you host code for other people as a business model

Or is a victim of one of those javascript based exploits when visiting a random site.

Any security researcher or engineer worth their salary is already planning for those theoretical vulnerabilities. Ideas like these are hashed out at the development meeting. Not fixed after the cart has left the barn.

And yet people use Linux instead of OpenBSD, because it turns out security isn't always the most important consideration.

Maybe, but maybe not. The fact that AMD has implemented a similar instruction set but is not vulnerable to many of the existing speculative attacks that plague Intel suggest that they could just have made more secure design decisions, whether it was intentional or not.

You're comparing apples to oranges. Operating system architectures can vary a lot. CPU architecture between Intel and AMD can't vary much since they both target x86. Every vulnerability found with Intel CPUs can and has been tested for against AMD CPUs which is something you simply cannot do with operating systems, and AMD CPUs have been found not to have the same vulnerabilities.

> CPU architecture between Intel and AMD can't vary much since they both target x86.

Completely and utterly false. The exploits being found exist at a point much lower than the x86 instruction set. ARM processors were also hit with speculative execution exploits.

You're focusing on something that doesn't really matter in the context of what he was saying, and ignoring the bigger truth which is that security researchers DID look at AMD processors and they DID find that they do not suffer from the vulnerabilities that plague Intel.

All the vulnerabilities. Speculative execution vulnerabilities were found in AMD, just not the meltdown vulnerability.

And, his point still stands. While intel has/had meltdown, which was pretty bad. That doesn't mean that a Meltdown like bug doesn't exist in AMD's hardware.

It's like finding a bug in the OpenJDK that isn't in Zulu and then declaring that "Zulu is more secure than the OpenJDK!"

Or an even closer example "Intel doesn't have the TLB bug[0]! Intel makes better CPUs!"

AMD isn't guaranteed free of all exploits. It is only guaranteed to not suffer specifically from meltdown.

[0] https://www.anandtech.com/show/2477/2

> All the vulnerabilities. Speculative execution vulnerabilities were found in AMD, just not the meltdown vulnerability.

Just Not Meltdown. Or SPOILER. Or Fallout. Or RIDL. Or ZombieLoad.

You're really underselling the difference between the two. AMD's processors have only shown vulnerability to the issues that are inherent to the nature of speculative execution (Spectre).

Intel, on the other hand, has suffered from no less than 5 or 6 separate disclosures of vulnerabilities from various places in their microarchitecture where they cut corners on process separation in order to gain speed. None of these exploits have been pulled off against AMD, despite many of the papers authors explicitly trying to,

You're doing exactly what you wrongly accuse me of...

The original rebuttal was AMD gets less researcher eyeballs because there are more Intel devices in the wild so it's expected that Intel has more vulnerabilities found.

This was fully correct, yet the GP and you apparently are fixated on the idea that AMD didn't have certain vulnerabilities that were originally found _by studying Intel CPUs_. Yet no big surprise most don't apply to AMD in that case... because they were found by studying Intel CPUs first.

>CPU architecture between Intel and AMD can't vary much since they both target x86

Yes they can. Instruction sets are just that, a bunch of op codes and "things" for a processor to do. How a processor actually performs them is open to implementation.

Right, it is like declaring that "Java bytecode is fixed, all JVMs are the same!"

Implementation matters a lot. Heck, it is WHY there are performance differences between AMD and Intel CPUs.

Reply on news.ycombinator.com