netdev - RE: [RFC PATCH iproute2] ip: Add support for setting MAC and VLAN on hardware queues

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] [day] [month] [year] [list]

Message-ID: <EA929A9653AAE14F841771FB1DE5A1365FA69A3201@rrsmsx501.amr.corp.intel.com>
Date:	Wed, 18 Nov 2009 15:07:23 -0700
From:	"Williams, Mitch A" <mitch.a.williams@...el.com>
To:	Stephen Hemminger <shemminger@...tta.com>,
	David Miller <davem@...emloft.net>
CC:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>
Subject: RE: [RFC PATCH iproute2] ip: Add support for setting MAC and VLAN
 on hardware queues

>From: Stephen Hemminger [mailto:shemminger@...tta.com]
>Sent: Wednesday, November 18, 2009 11:16 AM
>> >
>> > Is there anything to avoid prevent this from being misused by users who
>> > are doing multiqueue. Maybe we need equivalent of "mounted" flag that
>block
>> > devices have?
>>
>> It's a privileged config operation as far as I can tell.
>>
>> Given that, what could we possibly need to protect?
>>
>> This stuff looks basically fine to me.
>>
>
>I was thinking that maybe the general question of SR-IOV overlap with other
>multiqueue usage. How is it possible to be sure queue is not being used
>for other traffic?  The MAC stuff itself is fine, just an example where
>changing a queue being used for SR-IOV makes sense, but if being used
>for regular multiqueue receive doesn't.
>
>The filesystem example is that for years it was possible to do something
>dumb like do fsck on a mounted filesystem and cause trouble (on unix and
>early
>linux); but current systems don't allow it because it is stupid idea.
>

Right now, this is only intended for SR-IOV usage, and the ixgbe driver enforces that by returning error if you try to set filters on queue 0, which corresponds to the PF device. We could conceivably extend this for use with non-IOV device queues and filters, but we'd need to look long and hard at the use cases and semantics of "what is a queue?" before we do that.

In this case (SR-IOV), we really can't realistically do any policy enforcement aside from root privilege.  Yeah, it's a bad idea to change these filters on an active queue - the VM would just mysteriously stop receiving traffic.  OTOH, the driver can't tell for sure what's going on with the VF device. Is it running, unloaded, crashed, booting...? There's no way to tell.

So we have to allow the filters to be changed at any time, even if there's a possibility that the VM is using the queue. We have to trust that the VM manager/hypervisor/whatever knows what it's doing, because we have no choice.

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