Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751989AbaF2GUF (ORCPT ); Sun, 29 Jun 2014 02:20:05 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:46752 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751379AbaF2GUB (ORCPT ); Sun, 29 Jun 2014 02:20:01 -0400 MIME-Version: 1.0 In-Reply-To: References: <1403913966-4927-1-git-send-email-ast@plumgrid.com> <1403913966-4927-9-git-send-email-ast@plumgrid.com> Date: Sat, 28 Jun 2014 23:20:00 -0700 Message-ID: Subject: Re: [PATCH RFC net-next 08/14] bpf: add eBPF verifier From: Alexei Starovoitov To: Andy Lutomirski Cc: "David S. Miller" , Ingo Molnar , Linus Torvalds , Steven Rostedt , Daniel Borkmann , Chema Gonzalez , Eric Dumazet , Peter Zijlstra , Arnaldo Carvalho de Melo , Jiri Olsa , Thomas Gleixner , "H. Peter Anvin" , Andrew Morton , Kees Cook , Linux API , Network Development , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 28, 2014 at 6:58 PM, Andy Lutomirski wrote: >> These were great questions! I hope I answered them. If not, please >> continue asking. > > I have plenty more questions, but here's one right now: does anything > prevent programs from using pointers in comparisons, returning > pointers, or otherwise figuring out the value of a pointer? If so, I > think it would be worthwhile to prevent that so that eBPF programs > can't learn kernel addresses. when we decide to let non-root users load such programs, yes. Right now the goal is the opposite. Take a look at 'drop monitor' example. It stores kernel addresses where packets were dropped into a map, so that user space can read it. The goal of eBPF for tracing is to be able to see all corners of the kernel without being able to crash it. eBPF is a kernel module that cannot crash kernel or adversely affect the execution. Though in the future I'd like to expand applicability and let unprivileged users use them. In such cases exposing kernel addresses will be prevented. It's easy to tweak verifier to prevent comparison of pointers, storing pointers to a map or passing them into a function. The verifier is already tracking all pointers. There ways to leak them: store into map, pass to helper function, return from program, compare to constant, obfuscate via arithmetic. Prevention by verifier is trivial. Though not right now. User level security is a different topic. If I try to solve both 'root user safety' and 'non-root security' it will take ages to go anywhere. So this patch is root only. I'm deliberately not addressing non-root security for now. First step: root only, get kernel pieces in place, llvm upstream, perf plus all other user level tools. Just this step will take months. Then let's talk about non-root. I believe it will need minimal changes to verifier and no syscall uapi changes, but even if I'm wrong and new syscall would be needed, it's not a big deal. Adding things gradually is way better than trying to solve everything at once. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/