linux-kernel - Re: [PATCH v7 10/33] net: dummy

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:	Thu, 10 Jul 2014 12:12:28 +0200
From:	Tom Gundersen <teg@...m.no>
To:	Bjørn Mork <bjorn@...k.no>
Cc:	netdev <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	David Herrmann <dh.herrmann@...il.com>,
	Kay Sievers <kay@...y.org>,
	dingtianhong <dingtianhong@...wei.com>,
	Tan Xiaojun <tanxiaojun@...wei.com>,
	WANG Cong <xiyou.wangcong@...il.com>
Subject: Re: [PATCH v7 10/33] net: dummy - set name assign type

On Thu, Jul 10, 2014 at 11:31 AM, Bjørn Mork <bjorn@...k.no> wrote:
> Tom Gundersen <teg@...m.no> writes:
>
>> A fixed number of indistinguishable dummy devices are allocated at module init time,
>> the names are therefore PREDICTABLE rather than ENUM.
>
> OK?  So if I go do
>
>  modprobe dummy numdummies=2
>  ip link add type dummy
>  ip link add type dummy
>
> then I'd have dummy0 and dummy1 with NET_NAME_PREDICTABLE, but dummy2 and
> dummy3 with NET_NAME_ENUM (from your rtnetlink patch).

Correct. Granted, this is definitely a grey area (the distinction
between the name assign types is less important for virtual devices),
but I still think this makes sense:

The result of

modprobe dummy numdummies=2

is to create dummy0 and dummy1, always with the same names.

The result of

ip link add type dummy

is to create dummyX, where X depends on what came before.

> I think this just demonstrates that there aren't that many different
> name types.  There is no real difference between your NET_NAME_ENUM and
> NET_NAME_PREDICTABLE, resulting in arbitrary choices like this one.

It is true that in some cases the distinction is less important, but
that does not negate the usefulness: For instance, the kernel may
assign names to interfaces based on information provided by their
firmware. These names may be useful to keep, and it may be important
for userspace to be told that they are backed by something sensible.

> The same goes for NET_NAME_USER and NET_NAME_RENAMED. These are the same
> from a kernel point of view.

You mean to collapse the two, and just label renamed interfaces
NET_NAME_USER instead?

> If userspace wants to keep track of device
> name history then it is free to do so without any need for a RENAMED
> type.

Just for the record, I don't see how userspace can keep track of
device name history (as some of the history may predate userspace
being around). Getting the history is not important though, what we
care about is the nature of the current name.

Cheers,

Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/