I think it makes sense in a really pedantic way: "flaw" and "bug" have always been, in my observed experience of usage, terms used to refer to the consequences of oversights.
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.
Design choices don't need patches to fix them. Flaws and bugs do.
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.
> 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.
Your argument seems reasonable, until we bring to the table all the shit that Intel did to beat AMD out of the x86 market. These deeds were from their marketing department, so no relation with chip design per se, but as a company they were still actively trying and almost succeeded in killing any diversity in the x86 market.
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”
You sound like a lawyer and I don't mean that as a compliment. But alright, if this isn't a flaw, then breaking it wasn't an achievement, certainly quantum computation wouldn't be an achievement - or rather foreseeing and avoiding the consequences isn't, which is easier because of different time scales, but still.
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.