netdev - Re: Increasing skb->mark size

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: <56568E33.4090707@alliedtelesis.co.nz>
Date:	Thu, 26 Nov 2015 04:44:41 +0000
From:	Luuk Paulussen <Luuk.Paulussen@...iedtelesis.co.nz>
To:	Matt Bennett <Matt.Bennett@...iedtelesis.co.nz>,
	"fw@...len.de" <fw@...len.de>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Kyeong Yoo <Kyeong.Yoo@...iedtelesis.co.nz>
Subject: Re: Increasing skb->mark size



On 11/25/2015 09:56 AM, Matt Bennett wrote:
> On Tue, 2015-11-24 at 21:36 +0100, Florian Westphal wrote:
>> Matt Bennett <Matt.Bennett@...iedtelesis.co.nz> wrote:
>>> I'm emailing this list for feedback on the feasibility of increasing
>>> skb->mark or adding a new field for marking. Perhaps this extension
>>> could be done under a new CONFIG option. Perhaps there are other ways we
>>> could achieve the desired behaviour?
>> Well I pointed you towards connlabels which provide 128 bit of space
>> in the conntrack extension area but you did not tell me why you cannot
>> use it.
> Sorry, I moved the discussion to this list to hopefully gather some new
> ideas/opinions.
>
> While connlabels provide 128bits of space skb->mark is still only 32
> bits. Since we are using connection tracking to simply restore skb->mark
> the use of connlabels by itself doesn't solve the problem I outlined
> above. skb->mark would still needs to be increased in size.
I've been looking into this further and it does look like something like 
connlabels could be useful in certain cases.  For example, netfilter 
could be used to classify a packet based on its label, rather than 
saving the mark and then classifying/filtering based on the mark in the 
tc subsystem.  However, it looks like currently connlabels is set up 
around setting/clearing individual bits, rather than using masks, so 
while there are 128 bits, it doesn't actually give us that many more 
distinct marks.