netdev - Re: [RFC PATCH 0/2] RFC: Caching IPv6 exthdr in skb->cb[]

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] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1209040955460.1704@ja.ssi.bg>
Date:	Tue, 4 Sep 2012 10:26:21 +0300 (EEST)
From:	Julian Anastasov <ja@....bg>
To:	Jesper Dangaard Brouer <brouer@...hat.com>
cc:	Patrick McHardy <kaber@...sh.net>,
	Hans Schillstrom <hans@...illstrom.com>,
	Hans Schillstrom <hans.schillstrom@...csson.com>,
	netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
	Pablo Neira Ayuso <pablo@...filter.org>
Subject: Re: [RFC PATCH 0/2] RFC: Caching IPv6 exthdr in skb->cb[]


	Hello,

On Mon, 3 Sep 2012, Jesper Dangaard Brouer wrote:

> Hi Patrick and Hans,
> 
> This is my followup to:
>   [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS
> 
> Where you proposed improving the overall architecture of IPv6
> extension header parsing not only for IPVS but for other related
> Netfilter subsystems as well.
> 
> We discussed using/extending inet6_skb_parm/IP6CB.  There was not
> enough room for extending inet6_skb_parm directly, so I have
> introduced a struct inet6_skb_exthdr_cache/IP6CB_EXTHDR, which extend
> IP6CB.
> 
> The question is if this approach will work.  Can netfilter be allowed
> to modify data after inet6_skb_parm/IP6CB, given all the different
> HOOKs ?

	Yes, as long as we do not reach the protocol
receiving handlers, eg. tcp_v4_rcv. But the problem is 
that many modules can use this CB part but nobody knows
if it is valid - it is not reset.

	If data is part of IP6CB it is reset in ipv6_rcv
with memset(IP6CB(skb), 0, sizeof(struct inet6_skb_parm));

	One option is to extend this memset to cover this
new IP6CB_EXTHDR part if CONFIG_NF_DEFRAG_IPV6 is defined.
I.e. we can create new struct inet6_skb_parm_exthdr, DCCP, TCP
will continue to use/extend inet6_skb_parm but
ipv6_find_hdr_cb will know that their part is reset. Then
above memset can become:

memset(IP6CB_EXTHDR(skb), 0, sizeof(struct inet6_skb_parm_exthdr));

struct inet6_skb_parm_exthdr {
	struct inet6_skb_parm	h6;
#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV6)
	__u16	thoff; ...
	...
#endif
};

	Not sure if it should depend only on
CONFIG_NF_DEFRAG_IPV6.

> If we find this is a valid approach, then I'll update the IPVS patches
> to also use this.

Regards

--
Julian Anastasov <ja@....bg>
--
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