Hacker News new | past | comments | ask | show | jobs | submit login

That's not exactly true. Broadly speaking, there have been two very different kinds of speculative execution vulnerabilities with different security implications and workarounds. Spectre and its relatives are an attack on trusted code that process untrusted data using certain code patterns guarded by conditionals that can be speculatively executed; they're inherent to speculative execution past branches, but they require specific code patterns that can be avoided to work around the issue.

These vulnerabilites and Meltdown allow untrusted code to speculatively access data that it shouldn't be allowed to access at all, and use that speculative access to leak data itself. Unlike Spectre this can be (and to some extent has to be) fixed at the hardware level, because the hardware itself is failing to protect sensitive data. This class of vulnerability seems to have been mostly Intel-exclusive so far (with the main exception being one unreleased ARM chip that was vulnerable to Meltdown). There's nothing inherent about modern high-performance CPUs that requires them to be designed this way.

Edit: This slipped my mind, but Foreshadow / Level 1 Terminal Fault was yet another similar Intel-only processor vulnerability that allowed speculative access to data the current process should not be able to access. It's definitely a pattern.

Yes, that's true, several of the vulnerabilities involve checks that are performed late (not at time of speculative access, but at some point before instruction commit). Not excusing the design choice at all, but it's conceivable that an engineer could make this choice if (i) side-channel effects of the speculation are not considered at all, and (ii) the postponement of the check allows the load latency to be reduced. Again, not justifying, and the vulnerabilities are terrible, but there does seem to be a rational-given-some-assumptions way to reach such a decision.

I’m not a CPU architect, but it seems like Intel saved a couple gates by putting garbage instead of zeroes in the pipeline.

After reading more of the (limited, publicly known) details, it looks like the data leaked isn’t, strictly speaking, total garbage. But I do wonder whether Intel got a meaningful latency improvement by putting potentially wrong data into the pipeline instead of using zeroes or stalling. Zeroes or a stall would require knowing that the data is invalid before continuing with execution, which could be a performance issue.

Your not, but the gentlemen your replying to is. Bet you can’t guess where and what he worked on?

Not sure how to read this, but if you meant it as a personal attack that's totally not ok here.


Not sure how to read this either, but as a moderator if you strive to warn people on ambiguity you can’t discern I can assure you no harm intended per the rules cited

Yup, I worked for a bit at Intel, but I don't speak for them, I wasn't involved in any of the designs under discussion, and everything I'm saying here is public knowledge in the computer architecture community. I figured that the perspective from the academic comparch world might be interesting.

Hehehehe I love it! Thank you much. I was being a bit rousing/ambiguous as your commentary caught my attention and was a bit excited when I checked out your background.

> There's nothing inherent about modern high-performance CPUs that requires them to be designed this way.

Assuming by "designed this way" you mean: to speculatively execute past security checks, I'd disagree.

I'd say the relevant performance measure for CPUs (as opposed to other kinds of processor) is the speed at which they can execute serial operations. As electronic performance improvements offer increasingly marginal gains, we need to resort to improved parallelism. When operations are needfully serial due to dependency, as are security checks, the only way to accelerate that beyond the limits of the electronics is to make assumptions (speculations).

It's not inherently wrong to do this, but requires speculations never have effects outside of their assumptive execution context.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact