netdev - Re: BUG_ON in skb_segment, after bpf_skb_change

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, 27 Aug 2019 17:09:19 +0200
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Shmulik Ladkani <shmulik.ladkani@...il.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        netdev <netdev@...r.kernel.org>,
        Alexander Duyck <alexander.duyck@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Yonghong Song <yhs@...com>,
        Steffen Klassert <steffen.klassert@...unet.com>,
        shmulik@...anetworks.com, eyal@...anetworks.com
Subject: Re: BUG_ON in skb_segment, after bpf_skb_change_proto was applied



On 8/27/19 1:42 PM, Shmulik Ladkani wrote:
> On Mon, 26 Aug 2019 19:47:40 +0200
> Eric Dumazet <eric.dumazet@...il.com> wrote:
> 
>> On 8/26/19 4:07 PM, Shmulik Ladkani wrote:
>>>   - ipv4 forwarding to dummy1, where eBPF nat4-to-6 program is attached
>>>     at TC Egress (calls 'bpf_skb_change_proto()'), then redirect to ingress
>>>     on same device.
>>>     NOTE: 'bpf_skb_proto_4_to_6()' mangles 'shinfo->gso_size'  
>>
>> Doing this on an skb with a frag_list is doomed, in current gso_segment() state.
>>
>> A rewrite  would be needed (I believe I did so at some point, but Herbert Xu fought hard against it)
> 
> Thanks Eric,
> 
> - If a rewrite is still considered out of the question, how can one use
>   eBPF's bpf_skb_change_proto() safely without disabling GRO completely?
>   - e.g. is there a way to force the GROed skbs to fit into a layout that is
>     tolerated by skb_segment?
>   - alternatively can eBPF layer somehow enforce segmentation of the
>     original GROed skb before mangling the gso_size?
> 
> - Another thing that puzzles me is that we hit the BUG_ON rather rarely
>   and cannot yet reproduce synthetically. If skb_segment's handling of
>   skbs with a frag_list (that have gso_size mangled) is broken, I'd expect
>   to hit this more often... Any ideas?

skb_segment of a gro packet (especially with frag_list) is only supported 
if the geometry of the individual segments is not changed,
meaning that gso_size must remain the same.

> 
> - Suppose going for a rewrite, care to elaborate what's exactly missing
>   in skb_segment's logic?
>   I must admit I do not fully understand all the different code flows in
>   this function, it seems to support many different input skbs - any
>   assistance is highly appreciated.

Well, this is the point really.
The complexity of this function is so high that very few of us dare to touch it.