From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexei Starovoitov Subject: Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf Date: Sat, 17 Aug 2019 08:08:45 -0700 Message-ID: <20190817150843.4vsmzpwpcvzndjld@ast-mbp> References: <20190805192122.laxcaz75k4vxdspn@ast-mbp> <20190806011134.p5baub5l3t5fkmou@ast-mbp> <20190813215823.3sfbakzzjjykyng2@ast-mbp> <201908151203.FE87970@keescook> <20190815234622.t65oxm5mtfzy6fhg@ast-mbp.dhcp.thefacebook.com> <20190816214542.inpt6p655whc2ejw@ast-mbp.dhcp.thefacebook.com> <20190816222252.a7zizw7azkxnv3ot@wittgenstein> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20190816222252.a7zizw7azkxnv3ot@wittgenstein> Sender: netdev-owner@vger.kernel.org To: Christian Brauner Cc: Andy Lutomirski , Kees Cook , Andy Lutomirski , Song Liu , Networking , bpf , Alexei Starovoitov , Daniel Borkmann , Kernel Team , Lorenz Bauer , Jann Horn , Greg KH , Linux API , LSM List List-Id: linux-api@vger.kernel.org On Sat, Aug 17, 2019 at 12:22:53AM +0200, Christian Brauner wrote: > > (The one usecase I'd care about is to extend seccomp to do pointer-based > syscall filtering. Whether or not that'd require (unprivileged) ebpf is > up for discussion at KSummit.) Kees have been always against using ebpf in seccomp. I believe he still holds this opinion. Until he changes his mind let's stop bringing seccomp as a use case for unpriv bpf.