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

Date:	Wed, 18 Nov 2009 11:15:55 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	David Miller <davem@...emloft.net>
Cc:	jeffrey.t.kirsher@...el.com, netdev@...r.kernel.org,
	gospo@...hat.com, mitch.a.williams@...el.com
Subject: Re: [RFC PATCH iproute2] ip: Add support for setting MAC and VLAN
 on hardware queues

On Wed, 18 Nov 2009 10:07:28 -0800 (PST)
David Miller <davem@...emloft.net> wrote:

> From: Stephen Hemminger <shemminger@...tta.com>
> Date: Tue, 17 Nov 2009 14:06:41 -0800
> 
> > On Tue, 17 Nov 2009 13:55:07 -0800
> > Jeff Kirsher <jeffrey.t.kirsher@...el.com> wrote:
> > 
> >> From: Williams, Mitch A <mitch.a.williams@...el.com>
> >> 
> >> This patch adds support to the "ip" tool for setting the MAC address and
> >> VLAN filter for hardware device queues. This is most immediately useful for
> >> SR-IOV; for VF devices to be usable in the real world, the hypervisor or VM
> >> manager must be able to set these parameters before the VF device is
> >> assigned to any VM.
> >> 
> >> Signed-off-by: Mitch Williams <mitch.a.williams@...el.com>
> >> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
> > 
> > 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.

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