What is the scope of Spectre?
I will first need some terms. The “architected CPU state” (‘CS’ here) refers to that information that collectively concerns the logic of the sorts of programs that one buys a computer to run. This does not involve the nature of the privileged code even though related concepts for privileged code are vital for other reasons. We need to reason here about the simpler CS. The CS information is comprised of the state of memory, the registers, the program counter, and perhaps a few miscellaneous bits that the instruction definitions name. The CS is what a compiler reasons about as it produces machine code to match the semantics of a program written in some language. Historically the state of early computers was the CS plus IO details. Today the definition of the ISA (Instruction Set Architecture) consists largely of providing the function of a CS, and the current instruction, to produce the subsequent CS. This is the general goal and if it were met one would say that the ISA was deterministic.
There are a few exceptions however:
I propose to define a “Spectre attack” exploitation of nondeterminism of an ISA to derive secrets.
The goal here is to explore schemes involving new privileged code and possibly modifying hardware to support, and enforce a deterministic execution. The broad claim is that it is possible to run potentially malicious code in your machine that can compute using available multiprocessing, deterministically and thus be unable to acquire secrets. The code may be machine code but the environment will not look like Unix or any other platform that I aware of. The design is far from complete. Ideas are taken from languages Sisal and Kappa.