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: <55DDF954.1000903@gmail.com>
Date:	Wed, 26 Aug 2015 10:37:24 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Marcel Holtmann <marcel@...tmann.org>,
	"David S. Miller" <davem@...emloft.net>
CC:	Network Development <netdev@...r.kernel.org>, andrew@...n.ch,
	Guenter Roeck <linux@...ck-us.net>, jiri@...nulli.us,
	sfeldma@...il.com
Subject: Re: [PATCH RFC 0/5] net: L2 only interfaces

On 25/08/15 21:24, Marcel Holtmann wrote:
> Hi Dave,
> 
>>> This patch series implements a L2 only interface concept which
>>> basically denies any kind of IP address configuration on these
>>> interfaces, but still allows them to be used as configuration
>>> end-points to keep using ethtool and friends.
>>>
>>> A cleaner approach might be to finally come up with the concept of
>>> net_port which a net_device would be a superset of, but this still
>>> raises tons of questions as to whether we should be modifying
>>> userland tools to be able to configure/query these
>>> interfaces. During all the switch talks/discussions last year, it
>>> seemed to me like th L2-only interface is closest we have to a
>>> "network port".
>>>
>>> Comments, flames, flying tomatoes welcome!
>>
>> Interesting, indeed.
>>
>> Do you plan to extend this to defining a more minimal network device
>> sub-type as well?
>>
>> Then we can pass "net_device_common" or whatever around as a common
>> base type of actual net device "implementations".
>>
>> Or is you main goal just getting the L2-only semantic?
> 
> the other end of this could be also an IP only net_device where we do not have ethtool semantics.
> 
> We do have a need for a IPv6 only net_device when utilizing ARPHRD_6LOWPAN for 802.15.4 and Bluetooth LE. Skipping in_dev initialization there might be an interesting step towards that. Not sure how much entangled in_dev and in6_dev still are. If it works for IFF_L2_ONLY, it might work also in the other direction.

Just out of curiosity, is the aim for IPv6 only net_device to be denying
any kind of IPv4 configuration/tools, or is it for performance purposes?

The IFF_L2_ONLY flag would probably need to mean something like
(IFF_NO_IPV4 | IFF_NO_IPV6) such that you could decide which one of the
two IP stacks you want to use, or none.
-- 
Florian
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ