You don't see why being "aggressive" with speculatively loading data over a _protection boundary_ could be considered irresponsible? I for one, think AMD has the right to gloat if they want. It's not just AMD, besides the latest version of ARM it seems all the other CPU vendors decided to not be "aggressive" with their users' protected data (sparc, mips, amd, power, s390x).

Does it mean all those vendors and architects had PoC for years for this and were sitting on it? No but they could have had a hunch not to go that route. Just like a sane developer might have a hunch over opening a wide API surface to a server that contains sensitive data. It doesn't mean they know there is security vulnerability in one of the API endpoints, it's just sane practice.

> If next month a researcher develops Meltdown2 for AMD, are AMDs designers now suddenly idiots for missing an obvious security hole?

But who called any developers idiots here? I think you were the only one.

I think you are being unfair as the GP didn't call anybody an idiot for not caring about security.

It just calls them out for insisting that this is not a flaw or a bug.

This wasn't an oversight; this was more like... whatever you call the fact that we're still, today, choosing to employ (and even design new!) hash functions that quantum computers could probably break easily. We're making an intentional design choice, based on the perceived difficulty and current infeasability of a particular known class of attack against that design. That current hashes are vulnerable if-and-when a quantum computer comes along to crack them isn't really a "bug" or a "flaw" in our hashing algorithms; it's a known property of our hashing algorithms.

Or, for another analogy: there was a point in history when the peak of warfare was ships shooting guided missiles at other ships, and the targeted ships shooting smaller "countermissiles" that attempted to get in the way of the incoming missiles before they could hit anything important. Every missile had a faint heat signature, making it visible to infrared optics—this was an unavoidable consequence of the fact that missiles need engines to make them move. But for a long time, the idea of a heat-seeking countermissile was just infeasible or un-economical to implement, so little work was done to hide the emissions signatures of missiles. The emissions signature certainly wasn't a "bug"—it wasn't the result of an oversight; and it's a bit strange to call it a "flaw", insofar as there was no such thing as a missile that didn't have said "flaw" while still being a missile. It was a known property of the missile technology of the time. Or, if you want to think of it on a higher level, "missiles" themselves—anything that you might call a missile—had a categorical flaw.

In the same way, anything we might call a modern-day CPU is now known to have the categorical flaw of leaking at least some amount of information through speculative execution. You can minimize it (like you can minimize a missile's heat signature), but you can't get rid of it without making something we wouldn't even call a CPU any more (most things without speculative execution are, these days, considered microcontrollers.)

In that sense, I can understand Intel's insistence that they didn't make a flawed product: they made a perfectly good instance of a "computer processor"—it's just that "computer processors", as a category of product, have a problem.

You wouldn't blame the missile manufacturer for making missiles with visible emissions signatures, before heat-seeking countermissiles were invented. They didn't introduce a flaw. They made their product to order, and the order—the requirements, the demands of the customer—themselves contained the flaw, contained the supposition that it was okay to make a particular trade-off because it wasn't currently exploitable.

In the missile manufacturer's case, it was the government that said "sure, heat doesn't matter, just make it go fast"; and when heat-seeking countermissiles were invented, it was the government whose (lack of) intelligence foresight was to blame for not changing their requirements to anticipate that exploit.

In Intel's case, some customer could have foreseen the exploit and shifted the market toward demanding non-speculative-execution CPUs. Intel was just making what the customers asked for, and right up until the end, they were asking for the categorically-flawed product.

You seem to think that this issue is inherent to speculative execution - it is not. It is due to intel performing speculative execution in a flawed way. In particular, an incorrect branch prediction should have no detectable effect on the system, whereas here it does.

Branch prediction is not scoped for that. Branch prediction will always change microarchitecture state, which is always detectable at some level or another. The key takeaway for designers should be that even though microarchitecture state is not exposed in the datapath it is not secured from side channel exposure.

It’s basically like saying “we are building stuff customers wanted, we just also beat to death any other potential alternative they could want as well”

I don't think Intel's engineers are incompetent, but be careful about the reasoning you're using.

We did. We, the people you called "paranoid" while we quietly try to fix things. We're the ones trying to make sure that people don't die when cyber vulnerabilities are exploited by shitty actors.

I have a theory that this heavily relates to the feedback loops and signals in play. New features are positively observable and their impact is observable from release onwards.

When defending against unknown unknowns, security is unobservable. It's observable only in its absence. All that's left are heuristics and synthetic signals like pentesting.

I wrote a multi-thousand word essay on the topic, but for an internal audience. I don't know if I could properly share it.

My own speculation is that we got here in this industry though a complete absence of liability. Bugs are not a big deal, they are _expected_ now.

The only counter example I know of is Knuth's bug reward system.

Happy to be proven wrong however.

A) they are vulnerable to two out of the three attacks, which indicates they did not in fact consider speculative execution a danger

B) it is hard to believe that if they researched the topic at AMD, they wouldn't find this vulnerability in Intel processors a long time ago

It’s this protection that means that AMD processors are not subject to meltdown.

All CPU manufacturers appear to have been caught on the hop by Spectre (branch prediction history side channels).

I think it's worth noting that it's entirely possible, that if you are a CPU execution pipeline designer that you think about memory loads/stores, L1 cache, branch prediction and speculative execution, and it occurs to you that the cache gets polluted by spec exec, and the branches can be security checks.

But the solution is simple. If the branch is important, wait for it. (Load it into L1 cache before the branch - use a memory barrier.)

The fact that this is not in any ISA docs is a likely pointer toward the possibility that it in fact hadn't occurred to them.

These attacks are the same as any new invention. Easy to see once you've grasped the concept.

I'm neither supporting or refuting the commenter. Just explaining to you the meaning of the comment.

If I observe fact X which is "bleeding obvious", then it's not my responsibility to tell the world about X.

Of course this stuff isn't "bleeding obvious", but I'm going to assume that the AMD engineers thought that it was "obvious enough" to not explicitly to tell the world about it.

Besides... do you have any idea what kind of NDAs those engineers are going to have to sign?

Intel designers should of course be blamed for such issues - full price paying customers are now suffering from performance penalises for up to 30% on some workload, when each new generation of Intel processors give you 5-10% performance boost in the last 5-10 years. Sure, the issue is a surprise for everyone, but if they are designing processors to power billions of devices, they are expected and required to be exceptional.

Let's make it perfect clear - Intel designers don't have to be smarter, they can give up their market share to AMD. It is a privilege to design chips for the entire world, it is not a right. When things go wrong, they need to admit the mistakes and fix their craps, sadly Intel is putting too much efforts into its PR rubbish ATM.

Spectre is clever. Meltdown, as known today, is (mainly) an Intel major fuck-up.

The reason for the strong reaction over these flaws is not because of the severity of this issue, nor does anyone believe Intel engineers are idiots. They are getting blowback because they implemented a closed solution for a powerful feature - Management Extensions.

They lost a lot of trust, which makes it far harder to recover when new issues occur.

On a grander note, there are probably hundreds of even more esoteric side channel attacks all across the system since every process changes the system state. This is more like the beginning of a new style of attacks now that one is shown to be practical, rather than any particular entity's fault. Hardware designers will need to consider informational and physical isolation in a more rigorous way, and there may be theoretical limits that bound the performance-security tradeoff when you share resources.

I don't know if playing the blame game here is going to be productive. All CPUs are vulnerable to side channel attacks of various kinds and focusing on Meltdown specifically seems like missing the forest for the trees - especially as ARM has the same issue in some of their designs.

In this case, the cache is not being rolled back. Neither (presumably) is the branch predictor. And then what of the performance counters? (do they count if an instruction is not retired?). I see many potential attack vectors opening up and it's much harder to prove that any of these state changes can't be exploited.

Why would it be any different?

It seems that at least some ARM might be affected by both Spectre and Meltdown.

So far, I have only seen negative meltdown tests for older AMD cores. Is there anything known for Ryzen except for the PR by AMD (and the kernel patch, which might be based on the google project zero information about older AMD cores)?

While meltdown is "easy" to fix by not reading memory if unprivileged to do so, spectre is a lot harder. Even if the caches are made safe, for example by having "speculative" cache lines which will be renamed into the "true" cache when the speculative thread is actually accepted and retired: It's not the only place where there is hidden state. For example, the branch prediction might be affected, and might give a timing signal.

> We reported this issue to Intel, AMD and ARM on 2017-06-01.

I don't think they have been twidling their thumbs with such a huge discovery without informing constructors.

[1] https://googleprojectzero.blogspot.com/2018/01/reading-privi...

Perhaps it took so long to find because it's only relativity recently that companies have been paying people to break the hardware?

What do you mean by 'aggressive' here? Cause frankly, I think aggression isn't a good trait to be exploiting in business - it's not the same as competitiveness.

Is it 'they would have done this if they could but they didn't try hard enough', or is it 'they could have done this but didn't have the nerve to take the risk'?

In the latter case, I'd argue that a lack of willingness to trade off security against performance is a Good Thing in line with engineering ethics. In the former case, it seems like you're assuming business comeptition is always construed as a zero-sum game - is this correct?

The Spectre attack is a side effect of performing speculative execution without wiping caches, something that was, until yesterday, an intentional and clearly-chosen industry design direction, standard across almost every commercial CPU produced in the last 20 years, despite the known risk of "theoretical" timing attacks.

The only reason for Intel to make the decisions that led them to be vulnerable to Meltdown was to sacrifice correctness/safety for performance, and failing to consider the potential side effects of that sacrifice (cache heat). They obviously made a bad risk tradeoff there (though I don't necessarily fault them).

AMD could definitely make the argument that Meltdown was an irresponsible "benchmark cheat" from Intel.

EDIT: And let me further clarify, ARM was "cheating" and doing the permission check asynchronously on some models too (i.e., some of their chips are also vulnerable to Spectre in Kernel-space aka Meltdown). It's not solely an Intel issue.

Spectre does not need that -- but OTOH is more difficult to exploit; it is in a whole different category. There is a reason they have different names.