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: <20210210135605.GD2859@horizon.localdomain>
Date:   Wed, 10 Feb 2021 10:56:05 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Vlad Buslov <vladbu@...dia.com>, Jakub Kicinski <kuba@...nel.org>,
        Saeed Mahameed <saeed@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Netdev List <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 Tue, Feb 09, 2021 at 06:10:59PM +0200, Or Gerlitz wrote:
> On Tue, Feb 9, 2021 at 4:26 PM Vlad Buslov <vladbu@...dia.com> wrote:
> > On Mon 08 Feb 2021 at 22:22, Jakub Kicinski <kuba@...nel.org> wrote:
> > > On Mon, 8 Feb 2021 10:21:21 +0200 Vlad Buslov wrote:
> 
> > >> > 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?
> 
> > >> The tunnel endpoint IP address is configured on VF that is represented
> > >> by enp8s0f0_0 representor in example rules. The VF is on host.
> 
> > > This is very confusing, are you saying that the 7.7.7.5 is configured
> > > both on VF and VFrep? Could you provide a full picture of the config
> > > with IP addresses and routing?
> 
> > No, tunnel IP is configured on VF. That particular VF is in host [..]
> 
> What's the motivation for that? isn't that introducing 3x slow down?

Vlad please correct me if I'm wrong.

I think this boils down to not using the uplink representor as a real
interface. This way, the host can make use of 7.7.7.5 for other stuff
as well without passing (heavy) traffic through representor ports,
which are not meant for it.

So the host can have the IP 7.7.7.5 and also decapsulate vxlan traffic
on it, which wouldn't be possible/recommended otherwise.

Another moment that this gets visible is with VF LAG. When we bond the
uplink representors, add an IP to it and do vxlan decap, that IP is
meant only for the decap process and shouldn't be used for heavier
traffic as its passing through representor ports.

Then, tc config for decap need to be done on VF0rep and not on VF0
itself because that would be a security problem: one VF (which could
be on a netns) could steer packets to another VF at will.