Spectre can read from other processes! Meltdown can even read across privilege levels (userland to kernel). But within userland, spectre lets you read anything. See:
https://isc.sans.edu/forums/diary/Meltdown+and+Spectre+clear...
You can only read from a process that you have managed to compromise, and spectre is a new category of exploit vectors not an exploit in and of itself.
So you need a process that takes external inputs (you need some way to influence it), and then you need to figure out how that input can resolve to a viable exploit via spectre. If your input validation code is spectre-free (LFENCE, whatever) then you're probably good to go. You don't need everything in your app to be spectre free. In the blog's example, for instance, he just assumes that somehow an attacker can influence the input X. But if there's no way for an attacker to do that because X never comes from any externally-influenced thing then you didn't need any LFENCEs on it.
Ensuring that all your external-touching code is completely spectre-free is non-trivial, of course, but it's not like you can just arbitrarily exploit anything you want, and you don't need every array access to be LFENCE'd or mask'd.
I'm mentioning this because (at least to my understanding) in Spectre variant 2 the entire address space of the victim process can be used to find the "gadget" i.e. an usable target for the indirect branch. This means that making only your input validation code "spectre-free" is not good enough for variant 2. (This is why e.g. OpenSSH recently started using the (Spectre variant 2!) retpoline compiler flags of GCC/LLVM if available. See this thread for details: https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-Fe...)
I suppose if you mitigate the branch predictor poisoning (retpoline perhaps?) then this is not a concern any more.
But consider the example function in the article:
void victim_function_v01(size_t x) {
if (x < array1_size) {
temp &= array2[array1[x] * 512];
}
}
Assuming you've mitigated spectre v2, right?
If you are vulnerable to v2, I can take any other indirect branch in your program (which may appear after some "y" I can control as an input) and have it speculatively branch from there to this "temp &= ..." code, leaking the value of "y".
If you are not vulnerable to spectre v2, then I agree, the paths are much more limited and tied to speculative execution that is related to attacker-controlled values.