Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

Jiri Kosina
2018-01-09T19:37:58Z

On Fri, 5 Jan 2018, Dan Williams wrote:

[ ... snip ... ]
> Andi Kleen (1):
> x86, barrier: stop speculation for failed access_ok
>
> Dan Williams (13):
> x86: implement nospec_barrier()
> [media] uvcvideo: prevent bounds-check bypass via speculative execution
> carl9170: prevent bounds-check bypass via speculative execution
> p54: prevent bounds-check bypass via speculative execution
> qla2xxx: prevent bounds-check bypass via speculative execution
> cw1200: prevent bounds-check bypass via speculative execution
> Thermal/int340x: prevent bounds-check bypass via speculative execution
> ipv6: prevent bounds-check bypass via speculative execution
> ipv4: prevent bounds-check bypass via speculative execution
> vfs, fdtable: prevent bounds-check bypass via speculative execution
> net: mpls: prevent bounds-check bypass via speculative execution
> udf: prevent bounds-check bypass via speculative execution
> userns: prevent bounds-check bypass via speculative execution
>
> Mark Rutland (4):
> asm-generic/barrier: add generic nospec helpers
> Documentation: document nospec helpers
> arm64: implement nospec_ptr()
> arm: implement nospec_ptr()

So considering the recent publication of [1], how come we all of a sudden
don't need the barriers in ___bpf_prog_run(), namely for LD_IMM_DW and
LDX_MEM_##SIZEOP, and something comparable for eBPF JIT?

Is this going to be handled in eBPF in some other way?

Without that in place, and considering Jann Horn's paper, it would seem
like PTI doesn't really lock it down fully, right?

[1] https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=287305

--
Jiri Kosina
SUSE Labs