> Intel has no good hardware or microcode mitigation for spectre-like attacks

I was under the impression that for at least one category of attack, there is no hardware mitigation possible because it's a fundamental problem with the x86-64 design. Fixing it would require building a chip that uses some other architecture. Is that not the case?

That's not exactly true. You could build an x86-64 chip without these flaws, but it would require a new internal architecture with a lot more silicon.

One obvious approach would be to have two caches per core. Speculative execution would use a different cache than normal execution. If the speculative action is committed to, it swaps which cache is the normal one and which is the speculative one. Then you'd also need to flush the branch predictor on context changes. And a few other issues.

Nothing that's impossible to do, but it would require a huge amount of new design and a lot more silicon just to maintain the performance of current chips without mitigation.

It will very probably not be double caches and nothing that kind of order for requested new silicon area. Its only an annoyance because the design are not gonna change for solid Spectre resistance (at least for its currently known versions v1 and 2) for the next chips, because their design are already complete since month if not years, and yes, that would be very significant changes. But separating the caches? Never gonna happen. Anything taking the same space as separating the caches? Never gonna happen, and actually not needed.

Yes a solid Spectre fix will obviously make designers rethink their microarch in some deep aspects. But somewhat good mitigations should be available as soon as the next chips, and off-by-default is completely utterly insane. The OS is not part of the platform (except in some special cases that can disable the mitigation for performance if they like), and the platform is supposed to be retro-compatible, maybe not perfectly but reasonably. Ok it has already been somewhat less true than before in the few recent year, but lets not encourage that behavior. So shipping new CPU that are broken by default but can be somewhat less broken as an opt-in is an attempt to mask the level of the fuck-up, or maybe to avoid the creation of a new stepping. We should not tolerate that from Intel, a stepping is expensive but they have the money to do it.

My point was solely that there are ways to preserve x86-64 as an ISA, and listed the single most obvious way to go about it. I never suggested that it was the best solution, or that those changes would be made any time soon, or that Intel's behavior has been anything but atrocious.

Did you mean to respond to someone else, maybe?

I'm no chip designer, but maybe a 'small' speculation cache which allows quick moving to the real caches might be better just in terms of less cache needs. If there's not enough space then you can't speculate farther, and that's that.

Of course, that'd probably need more complex logic to manage this new cache, which makes things more difficult. Then again, not sure how two caches interacts with potential speculation across multiple branches (does Intel even do that?)

(FYI you're missing your [1] reference.)

Thanks, I had a footnote, but decided it would be more confusing than clarifying at the ELI5 level.