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: <87610ivv6u.fsf@tassilo.jf.intel.com>
Date:	Tue, 01 Dec 2015 11:13:29 -0800
From:	Andi Kleen <andi@...stfloor.org>
To:	Lorenzo Colitti <lorenzo@...gle.com>
Cc:	Matt Bennett <Matt.Bennett@...iedtelesis.co.nz>,
	"netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
	Luuk Paulussen <Luuk.Paulussen@...iedtelesis.co.nz>,
	davem@...emloft.net
Subject: Re: Increasing skb->mark size

Lorenzo Colitti <lorenzo@...gle.com> writes:

> On Wed, Nov 25, 2015 at 5:32 AM, 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.
>
> 64-bit marks (both skb->mark and sk->sk_mark) would be useful for
> hosts doing complex policy routing as well. Current Android releases
> use 20 of the 32 bits. If the mark were 64 bits, we could put the UID
> in it, and stop using ip rules to implement per-UID routing.

This would be be great. I've recently ran into some issues with
the overhead of the Android firewall setup.

So basically you need 4 extra bytes in sk_buff. How about:

- shrinking skb->priority to 2 byte
- skb_iff is either skb->dev->iff or 0. so it could be replaced with a
single bit flag for the 0 case.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only
--
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