netdev - Re: [PATCH] Add sk_mark route lookup support for IPv4 listening sockets, and for IPv4 multicast forwarding

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, 07 Oct 2009 22:39:28 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	zenczykowski@...il.com
Cc:	atis@...rotik.com, netdev@...r.kernel.org, panther@...abit.hu,
	eric.dumazet@...il.com, brian.haley@...com
Subject: Re: [PATCH] Add sk_mark route lookup support for IPv4 listening
 sockets, and for IPv4 multicast forwarding

From: Maciej Żenczykowski <zenczykowski@...il.com>
Date: Wed, 7 Oct 2009 17:03:30 -0700

> Should wrapping a packet into a tunnel clear the mark?
> Should perhaps the mark be a parameter of the tunnel (like ttl or qos,
> can be set or can be inherited)?

That's the big question.

It may be that the only logical thing we can do is only apply
the socket mark to the top-level path and that's what happens
now.

Because we really don't have any reasonable way to let the user
control where it applies.  We have no way for it to say "don't
apply the mark to the top-level path, but do apply it to the
multicast tunnel' or something like that.

So, to be honest, I'd say we should skip these skb->mark cases
for now.