[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMEtUuwRf--qyPu3rKB7-57KAu2NdsQdEpVRckqabmf61g+h-g@mail.gmail.com>
Date: Fri, 27 Jun 2014 23:43:03 -0700
From: Alexei Starovoitov <ast@...mgrid.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: "David S. Miller" <davem@...emloft.net>,
Ingo Molnar <mingo@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Steven Rostedt <rostedt@...dmis.org>,
Daniel Borkmann <dborkman@...hat.com>,
Chema Gonzalez <chema@...gle.com>,
Eric Dumazet <edumazet@...gle.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Jiri Olsa <jolsa@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
Linux API <linux-api@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC net-next 03/14] bpf: introduce syscall(BPF, ...) and
BPF maps
On Fri, Jun 27, 2014 at 11:25 PM, Andy Lutomirski <luto@...capital.net> wrote:
> On Fri, Jun 27, 2014 at 10:55 PM, Alexei Starovoitov <ast@...mgrid.com> wrote:
>> On Fri, Jun 27, 2014 at 5:16 PM, Andy Lutomirski <luto@...capital.net> wrote:
>>> On Fri, Jun 27, 2014 at 5:05 PM, Alexei Starovoitov <ast@...mgrid.com> wrote:
>>>> BPF syscall is a demux for different BPF releated commands.
>>>>
>>>> 'maps' is a generic storage of different types for sharing data between kernel
>>>> and userspace.
>>>>
>>>> The maps can be created/deleted from user space via BPF syscall:
>>>> - create a map with given id, type and attributes
>>>> map_id = bpf_map_create(int map_id, map_type, struct nlattr *attr, int len)
>>>> returns positive map id or negative error
>>>>
>>>> - delete map with given map id
>>>> err = bpf_map_delete(int map_id)
>>>> returns zero or negative error
>>>
>>> What's the scope of "id"? How is it secured?
>>
>> the map and program id space is global and it's cap_sys_admin only.
>> There is no pressing need to do it with per-user limits.
>> So the whole thing is root only for now.
>>
>
> Hmm. This may be unpleasant if you ever want to support non-root or
> namespaced operation.
I think it will be easy to extend it per namespace when we lift
root-only restriction. It will be seamless without user api changes.
> How hard would it be to give these things fds?
you mean programs/maps auto-terminate when creator process
exits? I thought about it and it's appealing at first glance, but
doesn't fit the model of existing tracepoint events which are global.
The programs attached to events need to live without 'daemon'
hanging around. Therefore I picked 'kernel module'- like method.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists