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 Okay, so I can't take a pointer, put it on the stack, take it back any part of it as an integer and use it for a tail call? Sounds like this is shaping up nicely! Thanks for adding all these checks. -Kees > 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. > > Yes, please ask questions and try to poke holes. Now it is time. > -- Kees Cook Chrome OS Security -- 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
