|
|
Log in / Subscribe / Register

Another round of speculative-execution vulnerabilities

Another round of speculative-execution vulnerabilities

Posted Aug 11, 2023 8:13 UTC (Fri) by excors (subscriber, #95769)
In reply to: Another round of speculative-execution vulnerabilities by farnz
Parent article: Another round of speculative-execution vulnerabilities

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.)


to post comments

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds