On Sat, Feb 04, 2017 at 09:05:29PM -0800, Andy Lutomirski wrote:
>
> I'm not saying that at all. I'm saying that this use case sounds
> valid, but maybe it could be solved differently. Here are some ideas:
Great. Combining multiple threads. Replied in bpf_sk_netns_id thread.
On Sat, Feb 4, 2017 at 8:37 PM, Alexei Starovoitov
wrote:
> On Sat, Feb 04, 2017 at 07:54:20PM -0800, Andy Lutomirski wrote:
>>
>> I've repeatedly asked how you plan to make a "don't override" flag
>> have sensible semantics when someone tries to add a new flag or change
>> the behavior to "don't
On Sat, Feb 04, 2017 at 07:54:20PM -0800, Andy Lutomirski wrote:
>
> I've repeatedly asked how you plan to make a "don't override" flag
> have sensible semantics when someone tries to add a new flag or change
> the behavior to "don't override but, rather then rejecting programs
> down the hierarchy
On Sat, Feb 4, 2017 at 7:48 PM, Alexei Starovoitov
wrote:
> On Sat, Feb 04, 2017 at 07:27:01PM -0800, Andy Lutomirski wrote:
>> On Sat, Feb 4, 2017 at 7:10 PM, Alexei Starovoitov
>> wrote:
>> > On Sat, Feb 04, 2017 at 09:07:19AM -0800, Andy Lutomirski wrote:
>> >> >> can see a namespaced view of
On Sat, Feb 4, 2017 at 7:35 PM, Alexei Starovoitov
wrote:
> On Sat, Feb 04, 2017 at 07:22:03PM -0800, Andy Lutomirski wrote:
>> On Sat, Feb 4, 2017 at 7:18 PM, Alexei Starovoitov
>> wrote:
>> > On Sat, Feb 04, 2017 at 09:08:38AM -0800, Andy Lutomirski wrote:
>> >> > So use-case would be that some
On Sat, Feb 04, 2017 at 07:27:01PM -0800, Andy Lutomirski wrote:
> On Sat, Feb 4, 2017 at 7:10 PM, Alexei Starovoitov
> wrote:
> > On Sat, Feb 04, 2017 at 09:07:19AM -0800, Andy Lutomirski wrote:
> >> >> can see a namespaced view of the world. For this to work, presumably
> >> >> we need to make
On Sat, Feb 04, 2017 at 07:22:03PM -0800, Andy Lutomirski wrote:
> On Sat, Feb 4, 2017 at 7:18 PM, Alexei Starovoitov
> wrote:
> > On Sat, Feb 04, 2017 at 09:08:38AM -0800, Andy Lutomirski wrote:
> >> > So use-case would be that someone wants to attach the very same
> >> > prog via tc to various n
On Sat, Feb 4, 2017 at 7:10 PM, Alexei Starovoitov
wrote:
> On Sat, Feb 04, 2017 at 09:07:19AM -0800, Andy Lutomirski wrote:
>> >> can see a namespaced view of the world. For this to work, presumably
>> >> we need to make sure that eBPF programs that are installed by programs
>> >> that are in a
On Sat, Feb 4, 2017 at 7:18 PM, Alexei Starovoitov
wrote:
> On Sat, Feb 04, 2017 at 09:08:38AM -0800, Andy Lutomirski wrote:
>> > So use-case would be that someone wants to attach the very same
>> > prog via tc to various netdevs sitting in different netns, and
>> > that prog looks up a map, contr
On Sat, Feb 04, 2017 at 09:08:38AM -0800, Andy Lutomirski wrote:
> > So use-case would be that someone wants to attach the very same
> > prog via tc to various netdevs sitting in different netns, and
> > that prog looks up a map, controlled by initns, with skb->netns_inum
> > as key and the resulti
On Sat, Feb 04, 2017 at 09:07:19AM -0800, Andy Lutomirski wrote:
> >> can see a namespaced view of the world. For this to work, presumably
> >> we need to make sure that eBPF programs that are installed by programs
> >> that are in a container don't see traffic that isn't in that
> >> container.
>
On Fri, Feb 3, 2017 at 3:42 PM, Daniel Borkmann wrote:
> On 02/04/2017 12:06 AM, Alexei Starovoitov wrote:
>>
>> On Fri, Feb 03, 2017 at 10:56:43PM +0100, Daniel Borkmann wrote:
>>>
>>> On 01/26/2017 04:27 AM, Alexei Starovoitov wrote:
in cases where bpf programs are looking at sockets a
On Fri, Feb 3, 2017 at 3:08 PM, Alexei Starovoitov
wrote:
> On Fri, Feb 03, 2017 at 01:00:47PM -0800, Andy Lutomirski wrote:
>>
>> ISTM any ability to migrate namespaces and to migrate eBPF programs
>> that know about namespaces needs to have the eBPF program firmly
>> rooted in some namespace (or
On Sat, Feb 04, 2017 at 12:42:31AM +0100, Daniel Borkmann wrote:
> On 02/04/2017 12:06 AM, Alexei Starovoitov wrote:
> >On Fri, Feb 03, 2017 at 10:56:43PM +0100, Daniel Borkmann wrote:
> >>On 01/26/2017 04:27 AM, Alexei Starovoitov wrote:
> >>>in cases where bpf programs are looking at sockets and
On 02/04/2017 12:06 AM, Alexei Starovoitov wrote:
On Fri, Feb 03, 2017 at 10:56:43PM +0100, Daniel Borkmann wrote:
On 01/26/2017 04:27 AM, Alexei Starovoitov wrote:
in cases where bpf programs are looking at sockets and packets
that belong to different netns, it could be useful to read netns in
On Fri, Feb 03, 2017 at 01:00:47PM -0800, Andy Lutomirski wrote:
>
> ISTM any ability to migrate namespaces and to migrate eBPF programs
> that know about namespaces needs to have the eBPF program firmly
> rooted in some namespace (or perhaps cgroup in this case) so that it
programs are already g
On Fri, Feb 03, 2017 at 10:56:43PM +0100, Daniel Borkmann wrote:
> On 01/26/2017 04:27 AM, Alexei Starovoitov wrote:
> >in cases where bpf programs are looking at sockets and packets
> >that belong to different netns, it could be useful to read netns inode,
> >so that programs can make intelligent
On 01/26/2017 04:27 AM, Alexei Starovoitov wrote:
in cases where bpf programs are looking at sockets and packets
that belong to different netns, it could be useful to read netns inode,
so that programs can make intelligent decisions.
For example to disallow raw sockets in all non-init netns the p
Andy Lutomirski writes:
> On Thu, Feb 2, 2017 at 8:33 PM, Eric W. Biederman
> wrote:
>> Alexei Starovoitov writes:
>>
>>> On 1/26/17 11:07 AM, Andy Lutomirski wrote:
On Thu, Jan 26, 2017 at 10:32 AM, Alexei Starovoitov wrote:
> On 1/26/17 10:12 AM, Andy Lutomirski wrote:
>>
>
On Thu, Feb 2, 2017 at 8:33 PM, Eric W. Biederman wrote:
> Alexei Starovoitov writes:
>
>> On 1/26/17 11:07 AM, Andy Lutomirski wrote:
>>> On Thu, Jan 26, 2017 at 10:32 AM, Alexei Starovoitov wrote:
On 1/26/17 10:12 AM, Andy Lutomirski wrote:
>
> On Thu, Jan 26, 2017 at 9:46 AM, Ale
Alexei Starovoitov writes:
> On Fri, Feb 03, 2017 at 05:33:45PM +1300, Eric W. Biederman wrote:
>>
>> The point is that we can make the inode number stable across migration
>> and the user space API for namespaces has been designed with that
>> possibility in mind.
>>
>> What you have proposed
On Fri, Feb 03, 2017 at 05:33:45PM +1300, Eric W. Biederman wrote:
>
> The point is that we can make the inode number stable across migration
> and the user space API for namespaces has been designed with that
> possibility in mind.
>
> What you have proposed is the equivalent of reporting a file
Alexei Starovoitov writes:
> On 1/26/17 11:07 AM, Andy Lutomirski wrote:
>> On Thu, Jan 26, 2017 at 10:32 AM, Alexei Starovoitov wrote:
>>> On 1/26/17 10:12 AM, Andy Lutomirski wrote:
On Thu, Jan 26, 2017 at 9:46 AM, Alexei Starovoitov wrote:
>
> On 1/26/17 8:37 AM, Andy Lutom
On 1/25/17 8:27 PM, Alexei Starovoitov wrote:
> in cases where bpf programs are looking at sockets and packets
> that belong to different netns, it could be useful to read netns inode,
> so that programs can make intelligent decisions.
> For example to disallow raw sockets in all non-init netns the
Eric, you cannot just stay silent on this thread for days at a time.
Alexei has sought your feedback in his latest post in this thread,
and your response is holding the entire discussion up.
Do not just give a terse response, which will just trigger Alexei
asking for more clarification. Put tim
On 1/26/17 11:07 AM, Andy Lutomirski wrote:
On Thu, Jan 26, 2017 at 10:32 AM, Alexei Starovoitov wrote:
On 1/26/17 10:12 AM, Andy Lutomirski wrote:
On Thu, Jan 26, 2017 at 9:46 AM, Alexei Starovoitov wrote:
On 1/26/17 8:37 AM, Andy Lutomirski wrote:
Think of bpf programs as safe kernel
On Thu, Jan 26, 2017 at 10:32 AM, Alexei Starovoitov wrote:
> On 1/26/17 10:12 AM, Andy Lutomirski wrote:
>>
>> On Thu, Jan 26, 2017 at 9:46 AM, Alexei Starovoitov wrote:
>>>
>>> On 1/26/17 8:37 AM, Andy Lutomirski wrote:
>
>
> Think of bpf programs as safe kernel modules. They don't
On 1/26/17 10:12 AM, Andy Lutomirski wrote:
On Thu, Jan 26, 2017 at 9:46 AM, Alexei Starovoitov wrote:
On 1/26/17 8:37 AM, Andy Lutomirski wrote:
Think of bpf programs as safe kernel modules. They don't have
confined boundaries and program authors, if not careful, can shoot
themselves in the
On Thu, Jan 26, 2017 at 9:46 AM, Alexei Starovoitov wrote:
> On 1/26/17 8:37 AM, Andy Lutomirski wrote:
>>>
>>> Think of bpf programs as safe kernel modules. They don't have
>>> confined boundaries and program authors, if not careful, can shoot
>>> themselves in the foot. We're not trying to preve
On 1/26/17 8:37 AM, Andy Lutomirski wrote:
Think of bpf programs as safe kernel modules. They don't have
confined boundaries and program authors, if not careful, can shoot
themselves in the foot. We're not trying to prevent that because
it's impossible to check that the program is sane. Just like
Hi Linus-
Can you weigh in here before we get stuck in a potentially unfortunate place?
On Wed, Jan 25, 2017 at 10:23 PM, Alexei Starovoitov wrote:
> On 1/25/17 9:46 PM, Eric W. Biederman wrote:
>>
>> Alexei Starovoitov writes:
>>
[...]
>>> Similarly TC cls_bpf/act_bpf and socket filters can
On 1/25/17 9:46 PM, Eric W. Biederman wrote:
Alexei Starovoitov writes:
in cases where bpf programs are looking at sockets and packets
that belong to different netns, it could be useful to read netns inode,
so that programs can make intelligent decisions.
For example to disallow raw sockets in
tetst teste tetet tetest
tetett
On 01/26/2017 01:46 PM, Eric W. Biederman wrote:
> Alexei Starovoitov writes:
>
>> in cases where bpf programs are look
Alexei Starovoitov writes:
> in cases where bpf programs are looking at sockets and packets
> that belong to different netns, it could be useful to read netns inode,
> so that programs can make intelligent decisions.
> For example to disallow raw sockets in all non-init netns the program can do:
in cases where bpf programs are looking at sockets and packets
that belong to different netns, it could be useful to read netns inode,
so that programs can make intelligent decisions.
For example to disallow raw sockets in all non-init netns the program can do:
if (sk->type == SOCK_RAW && sk->netns
35 matches
Mail list logo
