On 01/04/2018 08:17 AM, Rich Freeman wrote: > On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird <corbinb...@charter.net> wrote: >> According to the Project Zero documentation .... having BPF JIT enabled >> is the key to the exploit. >> >> The way the docs read ... can it be assumed that by having BPF JIT >> disabled on an AMD, that blocks this exploit? >> > I'm still working through the details, but AMD seems to only be > vulnerable to variant 1 (based on AMD's reports), and for Linux that > requires that BPF JIT be both built into the kernel (compile-time), > and enabled in sysctl (net.core.bpf_jit_enable). From what I can tell > variant 1 requires that the vulnerable code actually be executed in > the kernel security context. I'm sure a fix to BPF will be made to > close that. There might also be some other code that can be tricked > in the kernel but there are no reports of this. > > For variant 2 (not exploitable on AMD), it sounds like the BPF code > need merely be present in kernel virtual memory while running in user > security context. That would mean that it would need to be built at > compile-time, and loaded (if in a module), but it wouldn't have to be > enabled in sysctl. I didn't see any mention of it but I would think > that the PTI fixes might close this hole on Intel, since then when the > CPU is in user security context the BPF code would not be present in > virtual memory. Intel posted a separate compile-time fix to lkml > yesterday as well, with an amusing response from Linus in his usual > style, and an even more amusing subsequent joke about needing to add a > perl interpreter to the kernel. > > Variant 1 does exploit CPU behavior, but I suspect it could be fixed > with a change to gcc to recognize these kinds of indirect memory > references and ensure they're not executed speculatively. That fix > would be applicable to anything that runs untrusted code in a sandbox, > such as browsers. That variant isn't about crossing CPU privilege > boundaries so much as getting code that is legitimately being run to > leak state through the cache as a backchannel. > > Note: I'm not an expert on any of this stuff, and if somebody wants to > chime in with details/adjustments to the above I'm all ears. >
So .... kill all BPF JIT support / leave BPF JIT out of the kernel / no kernel modules either == attack Variant #1 fails. The "current workaround" ( for AMD CPU's ) is how I read it. Thanks for the info. Corbin
