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:

Read the clock
The 370 and many other machines have an unprivileged instruction to read a high precision clock.
Undefined
In order not to constrain engineers to produce special values in situations where no program is likely to care, the ISA specifically notes cases where the instruction will produce what ever is convenient for the hardware dieign.
Shared memory
read access to memory that agents other than the implicit CPU can write into.
Despite these sources of non determinism computer science has found reliable means to use computers. For some purposes these information sources are called ‘noise’ which the program can either exploit to its valid ends, or ignore. The malicious program may however be in a position to turn those information sources to evil ends such as deriving putative secrets from the noise.

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.

Regarding ‘undefined’, which the IBM 370 manual used a few times, I had an informal conversation with two or three engineers from IBM who agreed that the following was the case for the 370: It was entirely unclear whether we could get an official statement from IBM on this however.
SpectreRSB