On 01/04/2018 09:45 PM, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <a...@kernel.org>
>
> Under speculation, CPUs may mis-predict branches in bounds checks. Thus,
> memory accesses under a bounds check may be speculated even if the
> bounds check fails, providing a primitive for building a side channel.
>
> To avoid leaking kernel data round up array-based maps and mask the index
> after bounds check, so speculated load with out of bounds index will load
> either valid value from the array or zero from the padded area.
>
> To avoid duplicating map_lookup functions for root/unpriv always generate
> a sequence of bpf instructions equivalent to map_lookup function for
> array and array_of_maps map types when map was created by unpriv user.
> And unconditionally mask index for percpu_array, since it's fast enough,
> even when max_entries are not rounded to power of 2 for root user,
> since percpu_array doesn't have map_gen_lookup callback yet.
>
> If prog_array map is created by unpriv user replace
> bpf_tail_call(ctx, map, index);
> with
> if (index >= max_entries) {
> index &= map->index_mask;
> bpf_tail_call(ctx, map, index);
> }
> (along with roundup to power 2) to prevent out-of-bounds speculation.
> There is secondary redundant 'if (index >= max_entries)' in the interpreter
> and in all JITs, but they can be optimized later if necessary.
>
> Other array-like maps (cpumap, devmap, sockmap, perf_event_array,
> cgroup_array)
> cannot be used by unpriv, so no changes there.
>
> That fixes bpf side of "Variant 1: bounds check bypass (CVE-2017-5753)" on
> all architectures with and without JIT.
>
> Signed-off-by: Alexei Starovoitov <a...@kernel.org>
> ---
LGTM, I'll drop it on my test systems and start running with it.
Although I don't have any Variant 1 code to test, but seems that
is being covered by others.
Thanks!
Acked-by: John Fastabend <john.fastab...@gmail.com>
