netdev - Re: [PATCH net-next v15 4/7] sch_cake: Add NAT awareness to packet classifier

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: <20180523.172008.1067759293733489715.davem@davemloft.net>
Date:   Wed, 23 May 2018 17:20:08 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     toke@...e.dk
Cc:     netdev@...r.kernel.org, cake@...ts.bufferbloat.net,
        netfilter-devel@...r.kernel.org
Subject: Re: [PATCH net-next v15 4/7] sch_cake: Add NAT awareness to packet
 classifier

From: Toke Høiland-Jørgensen <toke@...e.dk>
Date: Wed, 23 May 2018 23:05:16 +0200

> Ah, right, that could work. Is there any particular field in sk_buff
> we should stomp on for this purpose, or would you prefer a new one?
> Looking through it, the only obvious one that comes to mind is, well,
> skb->_nfct :)
> 
> If we wanted to avoid bloating sk_buff, we could add a union with that,
> fill it in the flow dissector, and just let conntrack overwrite it if
> active; then detect which is which in Cake, and read the data we need
> from _nfct if conntrack is active, and from what the flow dissector
> stored otherwise.
> 
> Is that too many hoops to jump through to avoid adding an extra field?

Space is precious in sk_buff, so yes avoid adding new members at all
costs.

How much info do you need exactly?