netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.duyck@gmail.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Netdev <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Ido Schimmel <idosch@idosch.org>,
	chouhan.shreyansh630@gmail.com
Subject: Re: [PATCH net] ip_gre: validate csum_start only if CHECKSUM_PARTIAL
Date: Thu, 2 Sep 2021 14:17:00 -0700	[thread overview]
Message-ID: <CAKgT0UdtqJ+ECyDs1dv7ha4Bq12XaGiOQ6uvja5cy06dDR5ziw@mail.gmail.com> (raw)
In-Reply-To: <CA+FuTSfaN-wLzVq1UQhwiPgH=PKdcW+kz1PDxgfrLAnjWf8CKA@mail.gmail.com>

On Thu, Sep 2, 2021 at 1:30 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Thu, Sep 2, 2021 at 4:25 PM Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
> >
> > On Thu, Sep 2, 2021 at 12:38 PM Willem de Bruijn
> > <willemdebruijn.kernel@gmail.com> wrote:
> > >
> > > From: Willem de Bruijn <willemb@google.com>
> > >
> > > Only test integrity of csum_start if checksum offload is configured.
> > >
> > > With checksum offload and GRE tunnel checksum, gre_build_header will
> > > cheaply build the GRE checksum using local checksum offload. This
> > > depends on inner packet csum offload, and thus that csum_start points
> > > behind GRE. But validate this condition only with checksum offload.
> > >
> > > Link: https://lore.kernel.org/netdev/YS+h%2FtqCJJiQei+W@shredder/
> > > Fixes: 1d011c4803c7 ("ip_gre: add validation for csum_start")
> > > Signed-off-by: Willem de Bruijn <willemb@google.com>
> > > ---
> > >  net/ipv4/ip_gre.c | 5 ++++-
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> > > index 177d26d8fb9c..09311992a617 100644
> > > --- a/net/ipv4/ip_gre.c
> > > +++ b/net/ipv4/ip_gre.c
> > > @@ -473,8 +473,11 @@ static void __gre_xmit(struct sk_buff *skb, struct net_device *dev,
> > >
> > >  static int gre_handle_offloads(struct sk_buff *skb, bool csum)
> > >  {
> > > -       if (csum && skb_checksum_start(skb) < skb->data)
> > > +       /* Local checksum offload requires csum offload of the inner packet */
> > > +       if (csum && skb->ip_summed == CHECKSUM_PARTIAL &&
> > > +           skb_checksum_start(skb) < skb->data)
> > >                 return -EINVAL;
> > > +
> > >         return iptunnel_handle_offloads(skb, csum ? SKB_GSO_GRE_CSUM : SKB_GSO_GRE);
> > >  }
>
> Thanks for taking a look.
>
> > So a few minor nits.
> >
> > First I think we need this for both v4 and v6 since it looks like this
> > code is reproduced for net/ipv6/ip6_gre.c.
>
> I sent a separate patch for v6. Perhaps should have made it a series
> to make this more clear.

Yeah, that was part of the reason I assumed the ipv6 patch was overlooked.

> > Second I don't know if we even need to bother including the "csum"
> > portion of the lookup since that technically is just telling us if the
> > GRE tunnel is requesting a checksum or not and I am not sure that
> > applies to the fact that the inner L4 header is going to be what is
> > requesting the checksum offload most likely.
>
> This test introduced in the original patch specifically protects the
> GRE tunnel checksum calculation using lco_csum. The regular inner
> packet path likely is already robust (as similar bug reports would be
> more likely for that more common case).

I was just thinking in terms of shaving off some extra comparisons. I
suppose it depends on if this is being inlined or not. If it is being
inlined there are at least 2 cases where the if statement would be
dropped since csum is explicitly false. My thought was that by just
jumping straight to the skb->ip_summed check we can drop the lookup
for csum since it would be implied by the fact that skb->ip_summed is
being checked. It would create a broader check, but at the same time
it would reduce the number of comparisons in the call.

> > Also maybe this should be triggering a WARN_ON_ONCE if we hit this as
> > the path triggering this should be fixed rather than us silently
> > dropping frames. We should be figuring out what cases are resulting in
> > us getting CHECKSUM_PARTIAL without skb_checksum_start being set.
>
> We already know that bad packets can enter the kernel and trigger
> this, using packet sockets and virtio_net_hdr. Unfortunately, this
> *is* the fix.

It sounds almost like we need a CHECKSUM_DODGY to go along with the
SKB_GSO_DODGY in order to resolve these kinds of issues.

So essentially we have a source that we know can give us bad packets.
We really should be performing some sort of validation on these much
earlier in order to clean them up so that we don't have to add this
sort of exception handling code all over the Tx path.

  reply	other threads:[~2021-09-02 21:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02 19:34 [PATCH net] ip6_gre: validate csum_start only if CHECKSUM_PARTIAL Willem de Bruijn
2021-09-02 19:34 ` [PATCH net] ip_gre: " Willem de Bruijn
2021-09-02 20:25   ` Alexander Duyck
2021-09-02 20:29     ` Willem de Bruijn
2021-09-02 21:17       ` Alexander Duyck [this message]
2021-09-02 21:44         ` Willem de Bruijn
2021-09-03  2:01           ` Alexander Duyck
2021-09-03  2:40             ` Willem de Bruijn
2021-09-03 16:46               ` Alexander Duyck
2021-09-03 19:38                 ` Willem de Bruijn
2021-09-03 23:13                   ` Alexander Duyck
2021-09-04 14:45                     ` Willem de Bruijn
2021-09-04 15:35                       ` Alexander Duyck
2021-09-04 21:40                         ` Willem de Bruijn
2021-09-04 21:53                           ` Alexander Duyck
2021-09-04 22:05                             ` Willem de Bruijn
2021-09-04 23:47                               ` Alexander Duyck
2021-09-05 15:24                                 ` Willem de Bruijn
2021-09-05 15:53                                   ` Alexander Duyck
2021-09-06  3:02                                     ` Willem de Bruijn
2021-09-02 20:27 ` [PATCH net] ip6_gre: " Alexander Duyck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKgT0UdtqJ+ECyDs1dv7ha4Bq12XaGiOQ6uvja5cy06dDR5ziw@mail.gmail.com \
    --to=alexander.duyck@gmail.com \
    --cc=chouhan.shreyansh630@gmail.com \
    --cc=davem@davemloft.net \
    --cc=idosch@idosch.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=willemdebruijn.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).