Another round of speculative-execution vulnerabilities [LWN.net]

Another round of speculative-execution vulnerabilities

Posted Aug 10, 2023 22:29 UTC (Thu) by jmspeex (guest, #51639)
In reply to: Another round of speculative-execution vulnerabilities by willy
Parent article: Another round of speculative-execution vulnerabilities

Actually, even in-order CPUs typically use speculative execution. Not having speculative execution means you stall the entire pipeline on every conditional branch. Even the original Pentium I had a branch predictor (and hence speculative execution), possibly even the 486.

to post comments

Another round of speculative-execution vulnerabilities

Posted Aug 10, 2023 22:32 UTC (Thu) by farnz (subscriber, #17727) [Link] (3 responses)

The 486 only had pipeline stalls for resolving conditional branches; the Pentium used a branch predictor and very limited speculative execution of the predicted outcome, and the amount of speculative execution in Intel processors went up from there onwards to today's CPUs.

Another round of speculative-execution vulnerabilities

Posted Aug 11, 2023 8:13 UTC (Fri) by excors (subscriber, #95769) [Link] (2 responses)

Hmm, the "Pentium Processor Family Developer's Manual" describes a 5-stage pipeline (for non-MMX models):

> PF: Prefetch
> D1: Instruction Decode
> D2: Address Generate
> EX: Execute - ALU and Cache Access
> WB: Writeback

and says:

> In EX all u-pipe instructions and all v-pipe instructions except conditional branches are verified for correct branch prediction. [...] The final stage is Writeback (WB) where instructions are enabled to modify processor state and complete execution. In this stage, v-pipe conditional branches are verified for correct branch prediction.

(where the two pipes are: "The u-pipe can execute all integer and floating-point instructions. The v-pipe can execute simple integer instructions and the FXCH floating-point instruction.")

and:

> The Pentium processor uses a Branch Target Buffer (BTB) to predict the outcome of branch instructions which minimizes pipeline stalls due to prefetch delays. The Pentium processor accesses the BTB with the address of the instruction in the D1 stage. [...]
>
> A mispredicted branch (whether a BTB hit or miss) or a correctly predicted branch with the wrong target address will cause the pipelines to be flushed and the correct target to be fetched. Incorrectly predicted unconditional branches will incur an additional three clock delay, incorrectly predicted conditional branches in the u-pipe will incur an additional three clock delay, and incorrectly predicted conditional branches in the v-pipe will incur an additional four clock delay.

Apart from the quirk with v-pipe conditional branches, that sounds like all branch predictions are resolved by the EX stage. If the prediction made in D1 was wrong, then it doesn't EX the mispredicted instruction, it flushes the pipeline and starts again. There is speculative fetch and decode, but no speculative execution. Am I misinterpreting that, or using a different meaning of "speculative execution" or something?

(Speculative fetching sounds mostly harmless in relation to Spectre - it can't reveal any microarchitectural state except the contents of the BTB, in contrast to proper speculative execution where potentially-sensitive register contents are processed by the EX stages of potentially-bogus instructions and may be exposed through many microarchitectural side channels.)

Another round of speculative-execution vulnerabilities

Posted Aug 11, 2023 12:25 UTC (Fri) by tao (subscriber, #17563) [Link] (1 responses)

The difference in timing between a misprediction and a correct prediction will at the very least reveal state as to true/false for the predicted condition. Whether that information is enough or not is a wholly different matter.

Another round of speculative-execution vulnerabilities

Posted Aug 11, 2023 14:11 UTC (Fri) by excors (subscriber, #95769) [Link]

I think that can be solved by writing constant-time code when you're dealing with sensitive data, so it's never exposed to the branch predictor side channel, which you should be doing anyway to avoid other timing attacks. The problem with Spectre is that it can't be solved by writing perfectly correct side-channel-free code, because the CPU is not executing the code you wrote, it's executing some arbitrary code that you *didn't* write (when it's speculating past a misprediction), and that unwritten code may expose the data to side channels. Software developers can't take responsibility for code they didn't write, so it becomes a hardware issue.