netdev - Re: [PATCH RFC 0/5] net: L2 only interfaces

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 26 Aug 2015 10:56:09 -0700
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Florian Fainelli <f.fainelli@...il.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Network Development <netdev@...r.kernel.org>, andrew@...n.ch,
	Guenter Roeck <linux@...ck-us.net>,
	Jiri Pirko <jiri@...nulli.us>, sfeldma@...il.com
Subject: Re: [PATCH RFC 0/5] net: L2 only interfaces

Hi Florian,

>>>> 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?

when you have 6LoWPAN, then it would be actually good to forbid IPv4 configuration on these interface since they have no mapping whatsoever. Eventually it might allow us to decrease the size of the network stack for embedded sensor devices.

> 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.

I think IFF_NO_IPV4 and IFF_NO_IPV6 instead of IFF_L2_ONLY sounds like a good idea.

Regards

Marcel

--
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