netdev - Re: [net-next V2 01/17] net/mlx5: E-Switch, Refactor setting source port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210208132557.GB2959@horizon.localdomain>
Date:   Mon, 8 Feb 2021 10:25:57 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     Vlad Buslov <vladbu@...dia.com>
Cc:     Saeed Mahameed <saeed@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Mark Bloch <mbloch@...dia.com>,
        Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [net-next V2 01/17] net/mlx5: E-Switch, Refactor setting source
 port

On Mon, Feb 08, 2021 at 10:21:21AM +0200, Vlad Buslov wrote:
> 
> On Sat 06 Feb 2021 at 20:13, Marcelo Ricardo Leitner <marcelo.leitner@...il.com> wrote:
> > Hi,
> >
> > I didn't receive the cover letter, so I'm replying on this one. :-)
> >
> > This is nice. One thing is not clear to me yet. From the samples on
> > the cover letter:
> >
> > $ tc -s filter show dev enp8s0f0_1 ingress
> > filter protocol ip pref 4 flower chain 0
> > filter protocol ip pref 4 flower chain 0 handle 0x1
> >   dst_mac 0a:40:bd:30:89:99
> >   src_mac ca:2e:a7:3f:f5:0f
> >   eth_type ipv4
> >   ip_tos 0/0x3
> >   ip_flags nofrag
> >   in_hw in_hw_count 1
> >         action order 1: tunnel_key  set
> >         src_ip 7.7.7.5
> >         dst_ip 7.7.7.1
> >         ...
> >
> > $ tc -s filter show dev vxlan_sys_4789 ingress
> > filter protocol ip pref 4 flower chain 0
> > filter protocol ip pref 4 flower chain 0 handle 0x1
> >   dst_mac ca:2e:a7:3f:f5:0f
> >   src_mac 0a:40:bd:30:89:99
> >   eth_type ipv4
> >   enc_dst_ip 7.7.7.5
> >   enc_src_ip 7.7.7.1
> >   enc_key_id 98
> >   enc_dst_port 4789
> >   enc_tos 0
> >   ...
> >
> > These operations imply that 7.7.7.5 is configured on some interface on
> > the host. Most likely the VF representor itself, as that aids with ARP
> > resolution. Is that so?
> >
> > Thanks,
> > Marcelo
> 
> Hi Marcelo,
> 
> The tunnel endpoint IP address is configured on VF that is represented
> by enp8s0f0_0 representor in example rules. The VF is on host.

That's interesting and odd. The VF would be isolated by a netns and
not be visible by whoever is administrating the VF representor. Some
cooperation between the two entities (host and container, say) is
needed then, right? Because the host needs to know the endpoint IP
address that the container will be using, and vice-versa. If so, why
not offload the tunnel actions via the VF itself and avoid this need
for cooperation? Container privileges maybe?

Thx,
Marcelo