Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On Wed, Mar 14, 2018 at 8:37 PM, Alexei Starovoitov wrote: > On Wed, Mar 14, 2018 at 05:17:54PM -0700, Eric Dumazet wrote: >> >> >> On 03/14/2018 11:41 AM, Alexei Starovoitov wrote: >> > On Wed, Mar 14, 2018 at 11:00 AM, Alexei Starovoitov >> >

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On Wed, 14 Mar 2018 20:37:00 -0700, Alexei Starovoitov wrote: > Hanness expressed the reasons why RHEL doesn't support ipvlan long ago. > I couldn't find the complete link. This one mentions some of the issues: > https://www.mail-archive.com/netdev@vger.kernel.org/msg157614.html ipvlan improved a

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On Wed, Mar 14, 2018 at 05:17:54PM -0700, Eric Dumazet wrote: > > > On 03/14/2018 11:41 AM, Alexei Starovoitov wrote: > > On Wed, Mar 14, 2018 at 11:00 AM, Alexei Starovoitov > > wrote: > >> > >>> It seems this is exactly the case where a netns would be the correct

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On 3/14/18 4:27 PM, Daniel Borkmann wrote: On 03/14/2018 07:11 PM, Alexei Starovoitov wrote: On Wed, Mar 14, 2018 at 03:37:01PM +0100, Daniel Borkmann wrote: --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -133,6 +133,8 @@ enum bpf_prog_type { BPF_PROG_TYPE_SOCK_OPS,

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On 03/14/2018 11:41 AM, Alexei Starovoitov wrote: > On Wed, Mar 14, 2018 at 11:00 AM, Alexei Starovoitov > wrote: >> >>> It seems this is exactly the case where a netns would be the correct answer. >> >> Unfortuantely that's not the case. That's what I tried to

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On 03/14/2018 07:11 PM, Alexei Starovoitov wrote: > On Wed, Mar 14, 2018 at 03:37:01PM +0100, Daniel Borkmann wrote: >>> --- a/include/uapi/linux/bpf.h >>> +++ b/include/uapi/linux/bpf.h >>> @@ -133,6 +133,8 @@ enum bpf_prog_type { >>> BPF_PROG_TYPE_SOCK_OPS, >>> BPF_PROG_TYPE_SK_SKB, >>>

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On Wed, Mar 14, 2018 at 11:00 AM, Alexei Starovoitov wrote: > >> It seems this is exactly the case where a netns would be the correct answer. > > Unfortuantely that's not the case. That's what I tried to explain > in the cover letter: > "The setup involves

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On Wed, Mar 14, 2018 at 03:37:01PM +0100, Daniel Borkmann wrote: > > --- a/include/uapi/linux/bpf.h > > +++ b/include/uapi/linux/bpf.h > > @@ -133,6 +133,8 @@ enum bpf_prog_type { > > BPF_PROG_TYPE_SOCK_OPS, > > BPF_PROG_TYPE_SK_SKB, > > BPF_PROG_TYPE_CGROUP_DEVICE, > > +

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On Tue, Mar 13, 2018 at 11:21:08PM -0700, Eric Dumazet wrote: > > If I understand well, strace(1) will not show the real (after modification > by eBPF) IP/port ? correct. Just like it won't show anything after syscall entry, whether lsm acted, seccomp, etc > What about selinux and other LSM ?

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On 03/14/2018 03:37 PM, Daniel Borkmann wrote: > On 03/14/2018 04:39 AM, Alexei Starovoitov wrote: > [...] >> +#define BPF_CGROUP_RUN_PROG_INET4_BIND(sk, uaddr) \ >> +BPF_CGROUP_RUN_SA_PROG(sk, uaddr, BPF_CGROUP_INET4_BIND) >> + >> +#define

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On 03/14/2018 04:39 AM, Alexei Starovoitov wrote: [...] > +#define BPF_CGROUP_RUN_PROG_INET4_BIND(sk, uaddr) \ > + BPF_CGROUP_RUN_SA_PROG(sk, uaddr, BPF_CGROUP_INET4_BIND) > + > +#define BPF_CGROUP_RUN_PROG_INET6_BIND(sk, uaddr) \ > +

Re: [PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

On 03/13/2018 08:39 PM, Alexei Starovoitov wrote: From: Andrey Ignatov == The problem == There is a use-case when all processes inside a cgroup should use one single IP address on a host that has multiple IP configured. Those processes should use the IP for both ingress and

[PATCH RFC bpf-next 1/6] bpf: Hooks for sys_bind

From: Andrey Ignatov == The problem == There is a use-case when all processes inside a cgroup should use one single IP address on a host that has multiple IP configured. Those processes should use the IP for both ingress and egress, for TCP and UDP traffic. So TCP/UDP servers