In the Spectre variant 2, the branch target buffer (BTB) can be poisoned in another process. If the branch predictor is also using the virtual address to index the branch, why we can not train the branch predictor like training BTB in Spectre v1 attack?
1 Answers
If the branch predictor is also using the virtual address to index the branch, why we can not train the branch predictor like training BTB in Spectre v1 attack?
Simple answers:
We don't know the virtual address of another process
Since it's another process, we can't directly inject CPU instructions to another process to access the memory we need.
More detailed:
Sure, Spectre V1 and V2 use the same vulnerability -- branch predictor. The basic difference is that V1 works within the same process, while V2 works for among the processes.
A typical example of V1 is a JavaScript virtual machine. We can't access process memory from within the VM, because VM checks bounds of each memory access. But using Spectre V1 we can first train branch predictor for the VM and then speculatively access a memory within the current process.
Things get more complicated if we want to access another process, i.e. Spectre V2. First, we have to train the branch predictor of a remote process. There are many ways to do this, including the way you've mentioned: train local virtual address (if we know it).
Then we can't just ask remote process "please read this and this secret", so we have to use the technique called "return oriented programming" to speculatively execute pieces of code we need inside the remote process.
That is the main difference. But as I said, your proposal is valid and will definitely work on some CPUs and some circumstances.