netdev - Re: [PATCH net] gve: Fix an edge case for TSO skb validity check

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]

Message-ID: <CANH7hM4FEtF+VNvSg5PPPYWH8HzHpS+oQdW98=MP7cTu+nOA+g@mail.gmail.com>
Date: Fri, 19 Jul 2024 09:55:50 -0700
From: Bailey Forrest <bcf@...gle.com>
To: Praveen Kaligineedi <pkaligineedi@...gle.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>, netdev@...r.kernel.org, 
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, 
	willemb@...gle.com, shailend@...gle.com, hramamurthy@...gle.com, 
	csully@...gle.com, jfraker@...gle.com, stable@...r.kernel.org, 
	Jeroen de Borst <jeroendb@...gle.com>
Subject: Re: [PATCH net] gve: Fix an edge case for TSO skb validity check

On Fri, Jul 19, 2024 at 7:31 AM Praveen Kaligineedi
<pkaligineedi@...gle.com> wrote:
>
> On Thu, Jul 18, 2024 at 8:47 PM Willem de Bruijn
> <willemdebruijn.kernel@...il.com> wrote:
> >
> > On Thu, Jul 18, 2024 at 9:52 PM Praveen Kaligineedi
> > <pkaligineedi@...gle.com> wrote:
> > >
> > > On Thu, Jul 18, 2024 at 4:07 PM Willem de Bruijn
> > > <willemdebruijn.kernel@...il.com> wrote:
> > >
> > > > > +                      * segment, then it will count as two descriptors.
> > > > > +                      */
> > > > > +                     if (last_frag_size > GVE_TX_MAX_BUF_SIZE_DQO) {
> > > > > +                             int last_frag_remain = last_frag_size %
> > > > > +                                     GVE_TX_MAX_BUF_SIZE_DQO;
> > > > > +
> > > > > +                             /* If the last frag was evenly divisible by
> > > > > +                              * GVE_TX_MAX_BUF_SIZE_DQO, then it will not be
> > > > > +                              * split in the current segment.
> > > >
> > > > Is this true even if the segment did not start at the start of the frag?
> > > The comment probably is a bit confusing here. The current segment
> > > we are tracking could have a portion in the previous frag. The code
> > > assumed that the portion on the previous frag (if present) mapped to only
> > > one descriptor. However, that portion could have been split across two
> > > descriptors due to the restriction that each descriptor cannot exceed 16KB.
> >
> > >>> /* If the last frag was evenly divisible by
> > >>> +                                * GVE_TX_MAX_BUF_SIZE_DQO, then it will not be
> > >>>  +                              * split in the current segment.
> >
> > This is true because the smallest multiple of 16KB is 32KB, and the
> > largest gso_size at least for Ethernet will be 9K. But I don't think
> > that that is what is used here as the basis for this statement?
> >
> The largest Ethernet gso_size (9K) is less than GVE_TX_MAX_BUF_SIZE_DQO
> is an implicit assumption made in this patch and in that comment. Bailey,
> please correct me if I am wrong..

If last_frag_size is evenly divisible by GVE_TX_MAX_BUF_SIZE_DQO, it
doesn't hit the edge case we're looking for.

- If it's evenly divisible, then we know it will use exactly
(last_frag_size / GVE_TX_MAX_BUF_SIZE_DQO) descriptors
- GVE_TX_MAX_BUF_SIZE_DQO > 9k, so we know each descriptor won't
create a segment which exceeds the limit