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
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
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,
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,
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,
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
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
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
>> >
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
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
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
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
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
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
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
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
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.
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
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/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
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
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
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
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
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
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
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
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
tetst teste tetet tetest
tetett
On 01/26/2017 01:46 PM, Eric W. Biederman wrote:
> Alexei Starovoitov writes:
>
>> in cases where bpf
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
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 &&
35 matches
Mail list logo