Beyond Spectre v1 Sample Clauses

Beyond Spectre v1. We now discuss how to extend our framework to other xxxx- xxxxx execution attacks. For each attack, we discuss how to (1) extend our contracts, and (2) adjust our hardware semantics: • Spectre-BTB and Spectre-RSB: These variants speculate respectively over indirect jumps and return instructions. To support them, the spec-contracts can be extended to explore all possible mispredicted paths for a bounded number of steps before rolling back (similarly to the BRANCH rule in Figure 3). Moreover, our hardware semantics {| · |} can also easily be extended to handle these new forms of speculation. For instance, speculation over indirect jumps could be modeled similarly to the FETCH-BRANCH-HIT rule in §V. • Spectre-STL: This variant speculates over memory alias- ing over in-flight store and load operations. Extending our contracts to handle this new kind of speculation requires to modify the spec-contracts to model the effects of store-to-load forwarding resulting from memory aliasing predictions. This could be done similarly to Pitchfork [13]. That is, the spec semantics could keep track of the issued store x, e instruc- tions. Then, whenever a load y, e′ instruction is executed, one leaks. A corresponding contract can be captured by an execu- tion mode (similar to spec) that explores instructions following unconditional changes in control flow up to a bounded depth and exposes the corresponding observations, whereas our hardware semantics {| · |} can be extended to support this form of speculation similarly to FETCH-BRANCH-HIT rule in §V. • Meltdown and MDS: In Spectre-type attacks, transient ex- ecution is caused by control- and data-flow mispredictions. In Meltdown-type [2] attacks (encompassing both Meltdown [34] and data sampling attacks [30], [31]), transient execution is caused by instruction faults or microcode assists. Contracts for processors that are vulnerable to this kind of attacks would need to expose large portions of the memory space, which makes secure programming challenging.