You are thinking of a specific attack that uses the 2nd spectre vulnerability (poisoning of the indirect branch prediction) to attack the kernel. I'm sure in the following weeks other attacks to the kernel will appear that do not use the eBPF. The same vulnerability can be in principle be used to attack other processes. Still there are both software and firmware mitigations for this attack.
The real elephant in the room is the first spectre vulnerability (exploiting the normal jump predictor), which allows untrusted code (think JS) to read anything in the same process. Apparently most [1] CPUs are affected by this. There is currently no mitigation for this, other than rewriting applications to use separate address spaces, and even then, I think with carefully crafted inputs even that can be exploited.
[1] apparently simple, in-order cpus are not, but in principle there is no reason for the attack to work there as well.
edit: another possible mitigation for spectre v1 is converting all bound checks controlled by untrusted input to force non-speculation (via if-conversion). It is going to take a very long time to covert all applications (it might be easier for VMs and JITs).
The real elephant in the room is the first spectre vulnerability (exploiting the normal jump predictor), which allows untrusted code (think JS) to read anything in the same process. Apparently most [1] CPUs are affected by this. There is currently no mitigation for this, other than rewriting applications to use separate address spaces, and even then, I think with carefully crafted inputs even that can be exploited.
[1] apparently simple, in-order cpus are not, but in principle there is no reason for the attack to work there as well.
edit: another possible mitigation for spectre v1 is converting all bound checks controlled by untrusted input to force non-speculation (via if-conversion). It is going to take a very long time to covert all applications (it might be easier for VMs and JITs).