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]
Date: Sat, 9 Mar 2024 16:13:24 +0100
From: Richard Gobert <richardbgobert@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
 willemdebruijn.kernel@...il.com, dsahern@...nel.org, shuah@...nel.org,
 idosch@...dia.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v2 3/4] net: gro: set inner_network_header in
 receive phase

Eric Dumazet wrote:
> On Thu, Mar 7, 2024 at 2:28 PM Richard Gobert <richardbgobert@...il.com> wrote:
>>
>> This patch sets network_header and inner_network_header to their respective
>> values during the receive phase of GRO. This allows us to use
>> inner_network_header later on in GRO. network_header is already set in
>> dev_gro_receive and under encapsulation inner_network_header is set.
>>
> 
>> +static inline int skb_gro_network_offset(const struct sk_buff *skb)
>> +{
>> +       const u32 mask = NAPI_GRO_CB(skb)->encap_mark - 1;
>> +
>> +       return (skb_network_offset(skb) & mask) | (skb_inner_network_offset(skb) & ~mask);
> 
> Presumably this is not needed.
> 
>> +}
>> +
>>  static inline void *skb_gro_network_header(const struct sk_buff *skb)
>>  {
>> +       const int offset = skb_gro_network_offset(skb);
>> +
>>         if (skb_gro_may_pull(skb, skb_gro_offset(skb)))
>> -               return skb_gro_header_fast(skb, skb_network_offset(skb));
>> +               return skb_gro_header_fast(skb, offset);
>>
>> -       return skb_network_header(skb);
>> +       return skb->data + offset;
>>  }
> 
> I would instead add a new offset parameter to this function.
> 
> Again, ideally GRO should work without touching any skb->{offset}.
> 
> GRO stack should maintain the offsets it needs in its own storage
> (stack parameter, or other storage if needed)
> 
> Upper stack can not trust any of these skb fields, otherwise we would
> have some troubles with napi_reuse_skb()

Inner and outer network headers are needed for commit #4, I will store them
in the CB.

Moreover I will work on another patch series, that changes GRO receive phase
to use stack params as you suggested. (prev offset, and I will also work on a
version with data_offset too).

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ