netdev - Re: [PATCH net-next RFC 0/5] ipv6: sr: introduce seg6local End.BPF action

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]

Date:   Tue, 3 Apr 2018 15:25:31 +0100
From:   David Lebrun <dav.lebrun@...il.com>
To:     Mathieu Xhonneux <m.xhonneux@...il.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     netdev@...r.kernel.org, David Lebrun <dlebrun@...gle.com>,
        Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [PATCH net-next RFC 0/5] ipv6: sr: introduce seg6local End.BPF
 action

On 04/03/2018 02:40 PM, David Lebrun wrote:
> On 04/03/2018 12:16 PM, Mathieu Xhonneux wrote:
>>
>>> In patch 2 I was a bit concerned that:
>>> +       struct seg6_bpf_srh_state *srh_state = (struct 
>>> seg6_bpf_srh_state *)
>>> +                                              &skb->cb;
>>> would not collide with other users of skb->cb, but it seems the way
>>> the hook is placed such usage should always be valid.
>>> Would be good to add a comment describing the situation.
>> Yes, it's indeed a little hack, but this should be OK since the IPv6 
>> layer does
>> not use the cb field. Another solution would be to create a new field in
>> __sk_buff but it's more cumbersome.
>> I will add a comment.
> 
> Good point. The IPv6 layer *does* use the cb field through the IP6CB() 
> macro. It is first filled in ipv6_rcv() for ingress packets and used, 
> among others, in the input path by extension headers processing 
> functions to store EH offsets.
> 
> Given that input_action_end_bpf is called in the forwarding path      
> and terminates with a call to dst_input(), IP6CB() will be then reset by 
> ipv6_rcv(), and the use of skb->cb here indeed should not collide with 
> other users.

Actually I'm wrong here. dst_input() will call either ip6_input() or 
ip6_forward(), not ipv6_rcv(). Both functions expect IP6CB() to be set,
so using skb->cb here will interfere with them.

What about saving and restoring the IPv6 CB, similarly to what TCP does 
with tcp_v6_restore_cb() ?

David