netdev - Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address

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: <2408F875-69BE-45D3-8605-4AE5CDA4601C@chelsio.com>
Date:	Thu, 22 Jul 2010 17:26:09 -0700
From:	Casey Leedom <leedom@...lsio.com>
To:	Stefan Assmann <sassmann@...hat.com>
Cc:	"Rose, Gregory V" <gregory.v.rose@...el.com>,
	David Miller <davem@...emloft.net>, shemminger@...tta.com,
	andy@...yhouse.net, harald@...hat.com, bhutchings@...arflare.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	gospo@...hat.com,
	"Duyck, Alexander H" <alexander.h.duyck@...el.com>
Subject: Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address

On Jul 21, 2010, at 11:53 PM, Stefan Assmann wrote:

> Using the VF in the host is a feature and I'm sure people will think of
> ways to make good use of it. However the actual problem we've seen is a
> more practical one. So to pass-through a VF to a VM the host has to be
> aware that the VF exists. Therefore you usually have to enable the VF in
> the host (i.e. specify the max_vfs parameter). The device will be
> discovered by the system and because of the random MAC address udev
> ignores the new device. With the additional information we provide with
> our solution udev will be able to recognize the device by it's "device
> path" and handle it properly (until you decide to pass it to a VM or
> just be happy with it in the host).

 Or you simply don't have the VF Driver loaded in the "Domain 0" Control OS.  When we install the cxgb4 PF Driver with "num_vf=..." this enables the PCI-E SR-IOV Capabilities within the various PFs and the corresponding VF PCI Devices are instantiated and discovered by the Domain 0 Linux OS.  But without a cxgb4vf VF Driver loaded, those devices just sit there – available for "Device Assignment" to VMs.

> Remember the issue that lead to the proposal of renaming VFs to vfeth?
> That's exactly the problem we try to fix. Additional benefit of an
> "address assignment type" as Ben likes to call it would be the handling
> of MAC address stealing NICs.

 The above was mostly to cope with some SR-IOV Drivers using random MAC addresses for the VFs.

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