On Mon, Oct 5, 2015 at 2:12 PM, Alexei Starovoitov <ast@xxxxxxxxxxxx> wrote: > On 10/5/15 2:00 PM, Kees Cook wrote: >> >> On Mon, Oct 5, 2015 at 1:48 PM, Alexei Starovoitov<ast@xxxxxxxxxxxx> >> wrote: >>> >>> >In order to let unprivileged users load and execute eBPF programs >>> >teach verifier to prevent pointer leaks. >>> >Verifier will prevent >>> >- any arithmetic on pointers >>> > (except R10+Imm which is used to compute stack addresses) >>> >- comparison of pointers >>> >- passing pointers to helper functions >>> >- indirectly passing pointers in stack to helper functions >>> >- returning pointer from bpf program >>> >- storing pointers into ctx or maps >> >> Does the arithmetic restriction include using a pointer as an index to >> a maps-based tail call? I'm still worried about pointer-based >> side-effects. > > > the array maps that hold FDs (BPF_MAP_TYPE_PROG_ARRAY and > BPF_MAP_TYPE_PERF_EVENT_ARRAY) don't have lookup/update accessors > from the program side, so programs cannot see or manipulate > those pointers. > For the former only bpf_tail_call() is allowed that takes integer > index and jumps to it. And the latter map accessed with > bpf_perf_event_read() that also takes index only (this helper > is not available to socket filters anyway). > Also bpf_tail_call() can only jump to the program of the same type. > So I'm quite certain it's safe. At some point there will be an unprivileged way to create a map, though, and we don't want to let pointers get poked into the map. Or am I misunderstanding? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
