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]

Message-Id: <20091014.021505.181431380.davem@davemloft.net>
Date:	Wed, 14 Oct 2009 02:15:05 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	steve@...gwyn.com
Cc:	zenczykowski@...il.com, 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: steve@...gwyn.com
Date: Wed, 14 Oct 2009 08:23:19 +0100

> On Wed, Oct 14, 2009 at 12:51:56AM -0700, Maciej Żenczykowski wrote:
>> I'm thinking that the mark should be a tunnel parameter with values of
>> inherit or a constant.
>>
> Why not do this on a per-route basis (i.e. lets suppose we add a
> "setmark" parameter to each route) and this would allow changing
> a mark when a packet matches the route. This not only solves the
> tunnel case, but would be generically useful as well.
> 
> Since we have to look up routes anyway, it shouldn't add any
> real overhead to the routing process and we can benefit from
> all the existing infrastructure (route cache, etc).

This idea, I like :-)