netdev - Re: Does skb_metadata_differs really need to stop GRO aggregation?

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, 28 Nov 2023 14:30:06 +0100
From: Daniel Borkmann <daniel@...earbox.net>
To: Jesper Dangaard Brouer <hawk@...nel.org>
Cc: Yan Zhai <yan@...udflare.com>, Stanislav Fomichev <sdf@...gle.com>,
 Netdev <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
 Alexei Starovoitov <ast@...nel.org>, kernel-team
 <kernel-team@...udflare.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
 "David S. Miller" <davem@...emloft.net>,
 Jakub Sitnicki <jakub@...udflare.com>
Subject: Re: Does skb_metadata_differs really need to stop GRO aggregation?

On 11/28/23 2:06 PM, Jesper Dangaard Brouer wrote:
> On 11/28/23 13:37, Jesper Dangaard Brouer wrote:
>> Hi Daniel,
>>
>> I'm trying to understand why skb_metadata_differs() needed to block GRO ?
>>
>> I was looking at XDP storing information in metadata area that also
>> survives into SKBs layer.  E.g. the RX timestamp.
>>
>> Then I noticed that GRO code (gro_list_prepare) will not allow
>> aggregating if metadata isn't the same in all packets via
>> skb_metadata_differs().  Is this really needed?
>> Can we lift/remove this limitation?
> 
> (Answering myself)
> I understand/see now, that when an SKB gets GRO aggregated, I will
> "lose" access to the metadata information and only have access to the
> metadata in the "first" SKB.
> Thus, GRO layer still needs this check and it cannot know if the info
> was important or not.

^ This exactly in order to avoid loosing information for the upper stack. I'm
not sure if there is an alternative scheme we could do where BPF prog can tell
'it's okay to loose meta data if skb can get aggregated', and then we just skip
the below skb_metadata_differs() check. We could probably encode a flag in the
meta_len given the latter requires 4 byte alignment. Then BPF prog can decide.

> I wonder if there is a BPF hook, prior to GRO step, that could allow me
> to extract variable metadata and zero it out before GRO step.
> 
>> E.g. if I want to store a timestamp, then it will differ per packet.
>>
>> --Jesper
>>
>> Git history says it dates back to the original commit that added meta
>> pointer de8f3a83b0a0 ("bpf: add meta pointer for direct access") (author
>> Daniel).
>>
>>
>> diff --git a/net/core/gro.c b/net/core/gro.c
>> index 0759277dc14e..7fb6a6a24288 100644
>> --- a/net/core/gro.c
>> +++ b/net/core/gro.c
>> @@ -341,7 +341,7 @@ static void gro_list_prepare(const struct list_head *head,
>>
>>                  diffs = (unsigned long)p->dev ^ (unsigned long)skb->dev;
>>                  diffs |= p->vlan_all ^ skb->vlan_all;
>> -               diffs |= skb_metadata_differs(p, skb);
>> +               diffs |= skb_metadata_differs(p, skb); // Why?
>>                  if (maclen == ETH_HLEN)
>>                          diffs |= compare_ether_header(skb_mac_header(p),
>