Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor

[Corbin Bird]

On 01/04/2018 08:17 AM, Rich Freeman wrote:
> On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird <corbinbird@×××××××.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