linux-kernel - Re: [PATCH net-next v3 06/15] net: macsec: add nla support for changing the offloading selection

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: <20191216084641.GA288774@kwain>
Date:   Mon, 16 Dec 2019 09:46:41 +0100
From:   Antoine Tenart <antoine.tenart@...tlin.com>
To:     David Miller <davem@...emloft.net>
Cc:     antoine.tenart@...tlin.com, sd@...asysnail.net, andrew@...n.ch,
        f.fainelli@...il.com, hkallweit1@...il.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com,
        alexandre.belloni@...tlin.com, allan.nielsen@...rochip.com,
        camelia.groza@....com, Simon.Edelhaus@...antia.com,
        Igor.Russkikh@...antia.com, jakub.kicinski@...ronome.com
Subject: Re: [PATCH net-next v3 06/15] net: macsec: add nla support for
 changing the offloading selection

Hello David,

On Sun, Dec 15, 2019 at 01:44:52PM -0800, David Miller wrote:
> From: Antoine Tenart <antoine.tenart@...tlin.com>
> Date: Fri, 13 Dec 2019 16:48:35 +0100
> 
> > +static int macsec_upd_offload(struct sk_buff *skb, struct genl_info *info)
> > +{
> 
> This function is over the top and in fact confusing.
> 
> Really, if you want to make semantics sane, you have to require that no
> rules are installed when enabling offloading.  The required sequence of
> events if "enable offloading, add initial rules".
> 
> > +	/* Check the physical interface isn't offloading another interface
> > +	 * first.
> > +	 */
> > +	for_each_net(loop_net) {
> > +		for_each_netdev(loop_net, loop_dev) {
> > +			struct macsec_dev *priv;
> > +
> > +			if (!netif_is_macsec(loop_dev))
> > +				continue;
> > +
> > +			priv = macsec_priv(loop_dev);
> > +
> > +			if (!macsec_check_offload(MACSEC_OFFLOAD_PHY, priv))
> > +				continue;
> > +
> > +			if (priv->offload != MACSEC_OFFLOAD_OFF)
> > +				return -EBUSY;
> > +		}
> > +	}
> 
> You are rejecting the enabling of offloading on one interface if any
> interface in the entire system is doing macsec offload?  That doesn't
> make any sense at all.

You're right, it doesn't make sense to check all the interfaces in the
entire system.

> Really, just require that a macsec interface is "clean" (no rules installed
> yet) in order to enable offloading.

This would allow two different virtual MACsec interfaces with the same
underlying hardware device to be offloaded. This is problematic as we
would have no way to distinguish ingress packets between the two: once
an ingress packet has been processed by the MACsec hardware block we
have no way to retrieve the MACsec parameters specific to this packet,
and we can't know to which MACsec flow the packet is related.

The above check was in fact reworked in between v2 and v3 and an
important part disappeared: the idea was to check the underlying
interface was not already offloading another virtual MACsec interface.
The last check (was and) should be:

  if (priv->real_dev == real_dev && priv->offload != MACSEC_OFFLOAD_OFF)
	return -EBUSY;

Thanks!
Antoine

-- 
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com