Gentoo Archives: gentoo-user

From: Rich Freeman <rich0@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor
Date: Thu, 04 Jan 2018 14:17:35
Message-Id: CAGfcS_k3ycWn60Z8_ozORZD6cFMiuK699wT0_DRb-rVPAHi5rw@mail.gmail.com
In Reply to: Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor by Corbin Bird
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

Replies