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: <565E1A9F.7040906@iogearbox.net>
Date:	Tue, 01 Dec 2015 23:09:35 +0100
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Andi Kleen <andi@...stfloor.org>,
	Lorenzo Colitti <lorenzo@...gle.com>
CC:	Matt Bennett <Matt.Bennett@...iedtelesis.co.nz>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Luuk Paulussen <Luuk.Paulussen@...iedtelesis.co.nz>,
	davem@...emloft.net
Subject: Re: Increasing skb->mark size

On 12/01/2015 08:13 PM, Andi Kleen wrote:
> 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

That wouldn't work, see SO_PRIORITY and such (4 bytes) ...

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

... and that one wouldn't work on ingress.

Hmm, thinking out loud, maybe it makes sense to combine {mark, priority}
into a mark64 field as union, if the use-case allows to ignore/overwrite
priorities set by applications, or to infer them otherwise based on
different policies like net_prio cgroup (see skb_update_prio()).
--
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