1 |
On Thu, Jan 4, 2018 at 9:22 PM, R0b0t1 <r030t1@×××××.com> wrote: |
2 |
> |
3 |
> I think referring to BPF is a red herring, because it is really the |
4 |
> processor that is at fault. Not BPF. And yes, I'm aware of what AMD |
5 |
> claims. |
6 |
|
7 |
Of course the processor is at fault. However, in order to exploit the |
8 |
fault on an AMD processor you have to target a function running in the |
9 |
correct priv level. BPF JIT was a way to accomplish this on Linux, |
10 |
because it can be made to run code. |
11 |
|
12 |
If the kernel doesn't contain any susceptible code, then it can't be |
13 |
exploited, because for Spectre to work part of the code has to run |
14 |
with kernel privs. Otherwise an AMD CPU will block the memory |
15 |
accesses before they affect the cache. |
16 |
|
17 |
The only exploit that works entirely with code in userspace is variant |
18 |
3 (Meltdown), which is Intel-only, because Intel processors will |
19 |
speculatively fetch data at the wrong priv level which affects the |
20 |
cache (though the instruction will not retire). |
21 |
|
22 |
I'm willing to believe that there could be other functions in the |
23 |
kernel other than BPF which are also vulnerable, but which haven't |
24 |
been discovered. If somebody builds a compiler-level fix for this |
25 |
then that could address the problem more completely. I wouldn't be |
26 |
surprised if they're discovering variants of this for a while. Short |
27 |
of disabling cache updates during speculative execution entirely I'm |
28 |
not sure Spectre can be solved at the hardware level, and that |
29 |
probably would have a big performance impact. |
30 |
|
31 |
|
32 |
-- |
33 |
Rich |