netdev - Re: [PATCH net-next 07/13] ipv6: Change "final" protocol processing for encapsulation

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160513095102.64c80977@halley>
Date:	Fri, 13 May 2016 09:51:02 +0300
From:	Shmulik Ladkani <shmulik.ladkani@...il.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	<davem@...emloft.net>, <netdev@...r.kernel.org>,
	<kernel-team@...com>
Subject: Re: [PATCH net-next 07/13] ipv6: Change "final" protocol processing
 for encapsulation

Hi,

On Wed, 11 May 2016 09:47:27 -0700 Tom Herbert <tom@...bertland.com> wrote:
> When performing foo-over-UDP, UDP packets are processed by the
> encapsulation handler which returns another protocol to process.
> This may result in processing two (or more) protocols in the
> loop that are marked as INET6_PROTO_FINAL. The actions taken
> for hitting a final protocol, in particular the skb_postpull_rcsum
> can only be performed once.
> 
> This patch set adds a check of a final protocol has been seen. The
> rules are:
>   - If the final protocol has not been seen any protocol is processed
>     (final and non-final). In the case of a final protocol, the final
>     actions are taken (like the skb_postpull_rcsum)
>   - If a final protocol has been seen (e.g. an encapsulating UDP
>     header) then no further non-final protocols are allowed
>     (e.g. extension headers). For more final protocols the
>     final actions are not taken (e.g. skb_postpull_rcsum).
> 
> Signed-off-by: Tom Herbert <tom@...bertland.com>

Reviewed-by: Shmulik Ladkani <shmulik.ladkani@...il.com>

Out of curiousity, you execute the "final actions" on the first
INET6_PROTO_FINAL occurence. Would it make any sense to defer the
actions and do them upon the last INET6_PROTO_FINAL occurence?
Or must them get executed once we encounter the first INET6_PROTO_FINAL
proto handler?

Also, just a nit, seems better if commit title is
  'Ensure "final" protocol processing is performed once'

Thanks
Shmulik