Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755584AbcLUEB5 (ORCPT ); Tue, 20 Dec 2016 23:01:57 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:34435 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752084AbcLUEBz (ORCPT ); Tue, 20 Dec 2016 23:01:55 -0500 Date: Tue, 20 Dec 2016 20:01:49 -0800 From: Alexei Starovoitov To: Andy Lutomirski Cc: Daniel Mack , Andy Lutomirski , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , Kees Cook , Jann Horn , Tejun Heo , David Ahern , "David S. Miller" , Thomas Graf , Michael Kerrisk , Peter Zijlstra , Linux API , "linux-kernel@vger.kernel.org" , Network Development Subject: Re: Potential issues (security and otherwise) with the current cgroup-bpf API Message-ID: <20161221040147.GA23140@ast-mbp.thefacebook.com> References: <20161219205631.GA31242@ast-mbp.thefacebook.com> <20161220000254.GA58895@ast-mbp.thefacebook.com> <20161220031802.GA77838@ast-mbp.thefacebook.com> <9e378fb1-23ff-a239-d915-3d9aa26a999e@zonque.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1357 Lines: 26 On Tue, Dec 20, 2016 at 10:49:25AM -0800, Andy Lutomirski wrote: > >> FWIW, everywhere I say ioctl(), the bpf() syscall would be okay, too. > >> It doesn't make a semantic difference, except that I dislike > >> BPF_PROG_DETACH because that particular command isn't BPF-specific at > >> all. > > > > Well, I think it is; it pops the bpf program from a target and drops the > > reference on it. It's not much code, but it's certainly bpf-specific. > > I mean the interface isn't bpf-specific. If there was something that > wasn't bpf attached to the target, you'd still want an API to detach > it. This discussion won't go anywhere while you keep thinking that this api has to be generalized. As I explained several times earlier BPF_CGROUP_INET_SOCK_CREATE hook is bpf specific. There is nothing in the kernel that can take advantage of it today, so by definition the hook is bpf specific. Period. Saying that something in the future may come along that would want to use that is like saying I want to design the generic steering wheel for any car that will ever need it. Hence if you want to change 'target_fd' in BPF_PROG_ATTACH/DETACH cmds from being fd of open("cgroupdir") to fd of open("cgroupdir/cgroup.bpf") file inside it then I'm ok with that. All other proposals with non-extensible ioctls() and crazy text based per-hook permissions is nack.