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  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:	Mon, 30 Nov 2009 11:36:08 -0700
From:	"Williams, Mitch A" <>
To:	Simon Horman <>
CC:	Ben Hutchings <>,
	"Kirsher, Jeffrey T" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>
Subject: RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing
 hardware queue MAC and VLAN filters

>From: Simon Horman []
>Sent: Sunday, November 29, 2009 10:03 PM

>> The issue of which VF goes with which PF device can be deduced in
>> userspace via sysfs.
>Does this mean that the configuration of filtering for a VF needs
>to be done where the interface for the VF exists - e.g. in a KVM
>guest/Xen domU?

No, all of the configuration is done through the PF device.  What I was saying was that, given a specific VF PCI device (which would be passed through to the VM), you can use sysfs to determine which PF owns it, and then run the ip command to tell the PF to configure the VF.

>In terms of dealing with interfaces and the way that tools such as ip work
>that makes a lot of sense. But I wonder if it actually makes more sense
>from an administrative point of view to have this configuration go through
>the PF - e.g. the KVM host/Xen domO.

>From a policy and security standpoint, you can't allow the VM to handle its own hardware configuration. The host/hypervisor/VM Manager/boss has to handle this or you lose many of the advantages of virtualization (i.e. isolation, security, stability, etc).

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists