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:	Tue, 24 Nov 2009 19:38:28 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Arnd Bergmann <arnd@...db.de>,
	virtualization@...ts.linux-foundation.org,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Anna Fischer <anna.fischer@...com>, netdev@...r.kernel.org,
	bridge@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	Mark Smith <lk-netdev@...netdev.nosense.org>,
	Gerhard Stenzel <gerhard.stenzel@...ibm.com>,
	Jens Osterkamp <jens@...ux.vnet.ibm.com>,
	Patrick Mullaney <pmullaney@...ell.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	Edge Virtual Bridging <evb@...oogroups.com>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH 1/4] veth: move loopback logic to common location

Eric W. Biederman wrote:
> Patrick McHardy <kaber@...sh.net> writes:
> 
>> In the layered case (macvlan -> eth0) its common behaviour to
>> keep the mark however. But in case of different namespaces,
>> I think macvlan should also clear the mark on the dev_queue_xmit()
>> path since this is just a shortcut to looping the packets
>> through veth. In fact probably both of them should also clear
>> skb->priority so other namespaces don't accidentally misclassify
>> packets.
> 
> That is why I pushed for what is becoming dev_forward_skb.  So that
> we have one place where we can make all of those tweaks.  It seems
> like in every review we find another field that should be cleared/handled
> specially.
> 
> I don't quite follow what you intend with dev_queue_xmit when the macvlan
> is in one namespace and the real physical device is in another.  Are
> you mentioning that the packet classifier runs in the namespace where
> the primary device lives with packets from a different namespace?

Exactly. And I think we should make sure that the namespace of
the macvlan device can't (deliberately or accidentally) cause
misclassification.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ