Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756086AbcLTEot (ORCPT ); Mon, 19 Dec 2016 23:44:49 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:34858 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751088AbcLTEoq (ORCPT ); Mon, 19 Dec 2016 23:44:46 -0500 Date: Mon, 19 Dec 2016 20:44:41 -0800 From: Alexei Starovoitov To: Andy Lutomirski Cc: David Ahern , Andy Lutomirski , Daniel Mack , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , Kees Cook , Jann Horn , Tejun Heo , "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: <20161220044440.GB86803@ast-mbp.thefacebook.com> References: <20161219205631.GA31242@ast-mbp.thefacebook.com> <20161220000254.GA58895@ast-mbp.thefacebook.com> <2dbec775-6304-e44c-19c5-fbf07877e7b1@gmail.com> <80574175-3692-0278-a74e-23b752d44f73@gmail.com> 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: 1449 Lines: 46 On Mon, Dec 19, 2016 at 07:12:48PM -0800, Andy Lutomirski wrote: > > struct cgroup_bpf { > /* > * Store two sets of bpf_prog pointers, one for programs that are > * pinned directly to this cgroup, and one for those that are effective > * when this cgroup is accessed. > */ > struct bpf_prog *prog[MAX_BPF_ATTACH_TYPE]; > struct bpf_prog *effective[MAX_BPF_ATTACH_TYPE]; > }; > > in struct cgroup, there's a 'struct cgroup_bpf bpf;'. > > This would change to something like: > > struct cgroup_filter_slot { > struct bpf_prog *effective; > struct cgroup_filter_slot *next; > struct bpf_prog *local; > } > > local is NULL unless *this* cgroup has a filter. effective points to > the bpf_prog that's active in this cgroup or the nearest ancestor that > has a filter. next is NULL if there are no filters higher in the > chain or points to the next slot that has a filter. struct cgroup > has: > > struct cgroup_filter_slot filters[MAX_BPF_ATTACH_TYPE]; > > To evaluate it, you do: > > struct cgroup_filter_slot *slot = &cgroup->slot[the index]; > > if (!slot->effective) > return; > > do { > evaluate(slot->effective); > slot = slot->next; > } while (unlikely(slot)); yes. something like this can work as a future extension to support multiple programs for security use case. Please propose a patch. Again, it's not needed today and there is no rush to implement it.