Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756476AbcLTF1m (ORCPT ); Tue, 20 Dec 2016 00:27:42 -0500 Received: from mail-vk0-f54.google.com ([209.85.213.54]:33268 "EHLO mail-vk0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754005AbcLTF1k (ORCPT ); Tue, 20 Dec 2016 00:27:40 -0500 MIME-Version: 1.0 In-Reply-To: <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> <20161220044440.GB86803@ast-mbp.thefacebook.com> From: Andy Lutomirski Date: Mon, 19 Dec 2016 21:27:18 -0800 Message-ID: Subject: Re: Potential issues (security and otherwise) with the current cgroup-bpf API To: Alexei Starovoitov Cc: David Ahern , Andy Lutomirski , Daniel Mack , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , Kees Cook , Jann Horn , Tejun Heo , "David S. Miller" , Thomas Graf , Michael Kerrisk , Peter Zijlstra , Linux API , "linux-kernel@vger.kernel.org" , Network Development Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1686 Lines: 54 On Mon, Dec 19, 2016 at 8:44 PM, Alexei Starovoitov wrote: > 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. > If this happens after 4.10 and 4.10 is released as is, then this change would be an ABI break. --Andy