1 |
On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird <corbinbird@×××××××.net> wrote: |
2 |
> |
3 |
> According to the Project Zero documentation .... having BPF JIT enabled |
4 |
> is the key to the exploit. |
5 |
> |
6 |
> The way the docs read ... can it be assumed that by having BPF JIT |
7 |
> disabled on an AMD, that blocks this exploit? |
8 |
> |
9 |
|
10 |
I'm still working through the details, but AMD seems to only be |
11 |
vulnerable to variant 1 (based on AMD's reports), and for Linux that |
12 |
requires that BPF JIT be both built into the kernel (compile-time), |
13 |
and enabled in sysctl (net.core.bpf_jit_enable). From what I can tell |
14 |
variant 1 requires that the vulnerable code actually be executed in |
15 |
the kernel security context. I'm sure a fix to BPF will be made to |
16 |
close that. There might also be some other code that can be tricked |
17 |
in the kernel but there are no reports of this. |
18 |
|
19 |
For variant 2 (not exploitable on AMD), it sounds like the BPF code |
20 |
need merely be present in kernel virtual memory while running in user |
21 |
security context. That would mean that it would need to be built at |
22 |
compile-time, and loaded (if in a module), but it wouldn't have to be |
23 |
enabled in sysctl. I didn't see any mention of it but I would think |
24 |
that the PTI fixes might close this hole on Intel, since then when the |
25 |
CPU is in user security context the BPF code would not be present in |
26 |
virtual memory. Intel posted a separate compile-time fix to lkml |
27 |
yesterday as well, with an amusing response from Linus in his usual |
28 |
style, and an even more amusing subsequent joke about needing to add a |
29 |
perl interpreter to the kernel. |
30 |
|
31 |
Variant 1 does exploit CPU behavior, but I suspect it could be fixed |
32 |
with a change to gcc to recognize these kinds of indirect memory |
33 |
references and ensure they're not executed speculatively. That fix |
34 |
would be applicable to anything that runs untrusted code in a sandbox, |
35 |
such as browsers. That variant isn't about crossing CPU privilege |
36 |
boundaries so much as getting code that is legitimately being run to |
37 |
leak state through the cache as a backchannel. |
38 |
|
39 |
Note: I'm not an expert on any of this stuff, and if somebody wants to |
40 |
chime in with details/adjustments to the above I'm all ears. |
41 |
|
42 |
-- |
43 |
Rich |