In at least one of the variants, I believe that the branch predictor is primed in the attacker program with some value, say 0x00ABCDEF by jumping there consistently in certain circumstances.

Then the CPU switches to running another program that is allowed to access different memory. The CPU encounters a branch and predicts that it will land at 0x00ABCDEF and begins running attacker code briefly. Since it's working on the victim program, the code can access the victim program's data. After several cycles the CPU realizes it made the wrong prediction and NOPs out all of those instructions. However, the malicious code stores its results by shuffling things on the cache, which aren't rolled back because the CPU doesn't consider that to be nominal.

Therefore, the exploit can access memory from other programs. This is my limited understanding of Spectre. Reading the white paper, it must be much more complicated.

Apparently the CPU would normally stop accesses even speculatively when running from the malicious program (except for Meltdown, where it doesn't even stop that).

No, Spectre can only read its own memory, which makes it boring for programs, but interesting for stuff running interpreted code because it can suddenly peek outside, e.g. javascript.

Meltdown goes one step further in that it can read kernel memory (but not memory of other processes either, unless it was explicitly mapped in).

Spectre allows one process to extract the memory of another process (assuming certain conditions are met). I would not call that boring.

That's Spectre variant 2. Variant 1 is only able to read memory in its own address space.

Damn, that is indeed possible. And I thought I understood these conceptually, now I have to read the papers again.

As i understand it, you can extract memory from another process by controlling input data to that process. First sending data to train an exploitable branch prediction point for success and then sending data which will use a misprediction to extract some data.

The paper sited has an example C program that works within a single process, but sets the stage to show how it could be achieved across process boundaries.

C program source: https://pastebin.com/9GSrXhi3

This branch prediction inside a "gadget" needs to be mapped into the address spaces of both attacker and victim (i.e. shared lib). But even if the attacker can get this code to run on both sides and examine the dependent timings to find out underlying values, the victim code can't be tricked to sequentially read-by-speculation all its internal data.

Does the instruction cache get poisoned as well on a mispredict and carried over?