netdev - RE: Generic interface to make physical port number used by a netdevice available to user space

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: <E31FB011129F30488D5861F383904915210BA89DEC@BLRX7MCDC201.AMER.DELL.COM>
Date:	Mon, 10 Jun 2013 10:54:39 -0700
From:	<Narendra_K@...l.com>
To:	<john.fastabend@...il.com>, <bhutchings@...arflare.com>
CC:	<john.r.fastabend@...el.com>, <stephen@...workplumber.org>,
	<netdev@...r.kernel.org>
Subject: RE: Generic interface to make physical port number used by a
 netdevice available to user space

> -----Original Message-----
> From: John Fastabend [mailto:john.fastabend@...il.com]
> Sent: Friday, June 07, 2013 11:05 PM
> To: Ben Hutchings
> Cc: John Fastabend; K, Narendra; stephen@...workplumber.org;
> netdev@...r.kernel.org
> Subject: Re: Generic interface to make physical port number used by a
> netdevice available to user space
> 
> [...]
> 
> > Having looked at the qeth driver now, I think the comment in
> > netdevice.h should be changed to state that this is for distinguishing
> > devices that share a link-layer address, and the drivers using it for
> > other purposes should stop doing so (if that doesn't break userland).
> >
> 
> Agreed, the qeth driver eluded me, its not in ./drivers/net as you noted in
> the other thread.
> 
> > [...]
> >>> 3. Add a new field 'physport' to 'struct net_device' and export it to sysfs.
> >>
> >> Probably not we already have two fields that seem ill-defined no
> >> reason to add another to the confusion. If you absolutely can't make
> >> dev_id or if_port coherent then maybe but I really think one of the
> >> above two will work.
> >
> > I think we should tighten up documentation and implementation of the
> > existing fields, but there is still a need for this new one.
> >
> > One thing that needs to be clearly specified is the scope of the
> > physport identifier - the controller, board, physical machine, ... or
> > universe.  In a VM, controller and board scope are pretty useless as
> > it typically can't tell which devices belong to the same controller or
> > board anyway.  A universally unique identifier is probably not too
> > hard to implement as there is likely to be at least one MAC address
> > permanently assigned to each physical port.
> >
> > Ben.
> >
> 
> OK, sounds reasonable to me a new field should work.

1.  I think a universally unique physport identifier will be very useful.  If 'physport' is unique per NIC (say 0, 1, 2, 3) , then we would need PCI b/d/f to differentiate between two NICs.  But a universally unique identifier would not need any additional information. Also,  it seems like  the VM scenario  will not need any additional information if the VF (netdev) assigned to the guest exposes the unique identifier.

In the scenario of NIC partitions, universally unique identifier generation may have to consider that, each NIC partition which maps to a given physical port will have its own MAC address. (The SRIOV VF network interfaces could probably use PF's MAC address).  But  generation of a universally unique physport identifier would probably be driver specific.

2.  Also, thinking about the default value for 'physport' , could it be set to zero by default  ? A possible  interface could be

0   ==>   driver did not to set the identifier
> 0 ==> driver successfully set the identifier

With regards,
Narendra K
Linux Engineering
Dell Inc.