On Thu, Jan 4, 2018 at 8:17 AM, Rich Freeman <ri...@gentoo.org> 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.
>
I think this is missing the point - this specific attack may be tied
to BPF, but disabling BPF does not remove the underlying cause, which
is speculatively executed instructions modifying the processor state.
When news pieces are claiming that there is no way to fix this problem
save changing the hardware or taking a huge execution penalty they are
right.
I am still working through the information myself, but it looks like
BPF filters are an easy way to make sure you have something to look
for in kernelspace. Since you have something to look for, you can then
start asking yes or no questions about what is in cache that is
mirroring kernelspace memory. Once you find it, you can start to look
for other kernel structures that may contain more interesting
information (private keys), and then ask questions like "are the bytes
of the private key at position X equal to Y?" Eventually, you can read
arbitrary memory.
There are pieces claiming the details of the full attack allows
writing to kernel memory, and I suspect it is far easier in practice
to do the things detailed above. If AMD is not susceptible to one of
the attacks, that is because speculatively executed instructions do
not update the cache. But, if they do,
It is likely we will need to wait for the full details to be released
once the problem is addressed in secret.
Cheers,
R0b0t1
