netdev - Re: [PATCH 3/3] C/R: Basic support for network namespaces and devices (v2)

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]

Date:	Sat, 23 Jan 2010 01:25:37 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	danms@...ibm.com
Cc:	containers@...ts.osdl.org, netdev@...r.kernel.org,
	orenl@...rato.com
Subject: Re: [PATCH 3/3] C/R: Basic support for network namespaces and
 devices (v2)

From: Dan Smith <danms@...ibm.com>
Date: Fri, 22 Jan 2010 13:09:52 -0800

> +	if (strcmp(dev->name, "sit0") == 0) {
> +		return 0;                                    /* Skip sit0 */
> +	} else if (dev->ethtool_ops && dev->ethtool_ops->get_drvinfo) {
> +		dev->ethtool_ops->get_drvinfo(dev, &drvinfo);
> +		if (strcmp(drvinfo.driver, "veth") == 0)
> +			return 1;                            /* vethX is okay */
> +	} else if (strcmp(dev->name, "lo") == 0)
> +		return 1;                                    /* lo is okay */
 ...
> +	if (strcmp(dev->name, "lo") == 0)
> +		h->type = CKPT_NETDEV_LO;
> +	else if (strncmp(dev->name, "veth", 4) == 0) {
> +		h->type = CKPT_NETDEV_VETH;
> +		peer = veth_get_peer(dev);
> +	} else {

This is gross.  You can't do things this way.

First of all, devices can get whatever name the user wants
to assign to them.  If they want to rename the loopback
device to something other than "lo" they can.

You need another way.  Is it such a stretch of ingenuity to
simply add an attribute flag to struct netdev that you can test
here and perhaps a callback for what you need?

Your direct calls into these drivers, like the veth bits, will not
work if the driver is built modular.  It's one of several reasons
why doing things this way isn't going to work.

This misdesign is also why you find a need to get at the RTNL link ops
too.  You have no infrastructure for doing what you need to do
generically, so instead you are forced to directly call into drivers
and export RTNL internals needlessly.

This needs a lot of work, sorry.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html