From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Jason Wang <jasowang@redhat.com>,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Szabolcs Nagy <szabolcs.nagy@arm.com>,
netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
edumazet@google.com, pabeni@redhat.com, arefev@swemel.ru,
alexander.duyck@gmail.com,
Willem de Bruijn <willemb@google.com>,
stable@vger.kernel.org, Jakub Sitnicki <jakub@cloudflare.com>,
Felix Fietkau <nbd@nbd.name>, Mark Brown <broonie@kernel.org>,
Yury Khrustalev <yury.khrustalev@arm.com>,
nd@arm.com
Subject: Re: [PATCH net v2] net: drop bad gso csum_start and offset in virtio_net_hdr
Date: Mon, 09 Sep 2024 21:12:48 -0400 [thread overview]
Message-ID: <66df9d10e88d2_81fd329432@willemb.c.googlers.com.notmuch> (raw)
In-Reply-To: <66df641780764_7585d294af@willemb.c.googlers.com.notmuch>
Willem de Bruijn wrote:
> Willem de Bruijn wrote:
> > > > > > So I guess VIRTIO_NET_HDR_GSO_* without VIRTIO_NET_HDR_F_DATA_VALID
> > > > > > would be wrong on rx.
> > > > > >
> > > > > > But the new check
> > > > > >
> > > > > > if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > case SKB_GSO_TCPV4:
> > > > > > case SKB_GSO_TCPV6:
> > > > > > if (skb->csum_offset != offsetof(struct tcphdr, check))
> > > > > > return -EINVAL;
> > > > > >
> > > > > > should be limited to callers of virtio_net_hdr_to_skb on the tx/GSO path.
> > > > > >
> > > > > > Looking what the cleanest/minimal patch is to accomplish that.
> > > > > >
> > > > >
> > > > > virtio_net_hdr_to_skb() translates virtio-net header to skb metadata,
> > > > > so it's RX. For TX the helper should be virtio_net_hdr_from_skb()
> > > > > which translates skb metadata to virtio hdr.
> > > >
> > > > virtio_net_hdr_to_skb is used by PF_PACKET, tun and tap
> > >
> > > Exactly.
> > >
> > > > when injecting a packet into the egress path.
> > >
> > > For tuntap it's still the RX path. For PF_PACEKT and macvtap, it's the tx.
> > >
> > > Maybe a new parameter to virtio_net_hdr_to_skb()?
> >
> > This is the most straightforward approach. But requires changse to all
> > callers, in a patch targeting all the stable branches.
> >
> > I'd prefer if we can detect ingress vs egress directly.
>
> Not doing this, because both on ingress and egress the allowed
> ip_summed types are more relaxed than I imagined.
>
> Let's just make the check more narrow to avoid such false positives.
>
> GRO indeed allows CHECKSUM_NONE.
>
> But TSO also accepts packets that are not CHECKSUM_PARTIAL, and will
> fix up csum_start/csum_off. In tcp4_gso_segment:
>
> if (unlikely(skb->ip_summed != CHECKSUM_PARTIAL)) {
> const struct iphdr *iph = ip_hdr(skb);
> struct tcphdr *th = tcp_hdr(skb);
>
> /* Set up checksum pseudo header, usually expect stack to
> * have done this already.
> */
>
> th->check = 0;
> skb->ip_summed = CHECKSUM_PARTIAL;
> __tcp_v4_send_check(skb, iph->saddr, iph->daddr);
> }
>
> With __tcp_v4_send_check:
>
> void __tcp_v4_send_check(struct sk_buff *skb, __be32 saddr, __be32 daddr)
> {
> struct tcphdr *th = tcp_hdr(skb);
>
> th->check = ~tcp_v4_check(skb->len, saddr, daddr, 0);
> skb->csum_start = skb_transport_header(skb) - skb->head;
> skb->csum_offset = offsetof(struct tcphdr, check);
> }
>
> That means that we can relax the check on input from userspace to
> bad CHECKSUM_PARTIAL input:
>
> @@ -173,7 +173,8 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
> break;
> case SKB_GSO_TCPV4:
> case SKB_GSO_TCPV6:
> - if (skb->csum_offset != offsetof(struct tcphdr, check))
> + if (skb->ip_summed == CHECKSUM_PARTIAL &&
> + skb->csum_offset != offsetof(struct tcphdr, check))
> return -EINVAL;
>
> I've verified that this test still catches the bad packet from the
> syzkaller report in the Link in the commit.
Sent: https://lore.kernel.org/netdev/20240910004033.530313-1-willemdebruijn.kernel@gmail.com/T/#u
> > Based on ip_summed, pkt_type, is_skb_wmem or so. But so far have not
> > found a suitable condition.
> >
> > I noticed something else: as you point out TUN is ingress. Unlike
> > virtnet_receive, it does not set ip_summed to CHECKSUM_UNNECESSARY if
> > VIRTIO_NET_HDR_F_DATA_VALID. It probably should. GRO expects packets
> > to have had their integrity verified. CHECKSUM_NONE on ingress is not
> > correct for GRO.
Actually CHECKSUM_NONE is allowed. It just triggers software checksum
validation.
Tun by default does not use GRO, only if enabling IFF_NAPI.
If a packet arrives at GRO with CHECKSUM_PARTIAL, then its checksum is
assumed valid, per __skb_gro_checksum_validate_needed. So that would
be one way for tun users today to get efficient GRO.
> > And also related: no GRO should be generated by a device unless
> > VIRTIO_NET_HDR_F_DATA_VALID is also passed? I have to check the spec
> > if it says anything about this.
Given that GRO handles !CHECKSUM_UNNECESSARY, probably no need to
require VIRTIO_NET_HDR_F_DATA_VALID with virtio GRO either.
next prev parent reply other threads:[~2024-09-10 1:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 20:10 [PATCH net v2] net: drop bad gso csum_start and offset in virtio_net_hdr Willem de Bruijn
2024-07-31 2:00 ` patchwork-bot+netdevbpf
2024-09-06 14:35 ` Szabolcs Nagy
2024-09-06 15:52 ` Willem de Bruijn
2024-09-08 20:09 ` Willem de Bruijn
2024-09-08 20:43 ` Michael S. Tsirkin
2024-09-09 2:33 ` Jason Wang
2024-09-09 3:02 ` Willem de Bruijn
2024-09-09 3:24 ` Jason Wang
2024-09-09 3:39 ` Willem de Bruijn
2024-09-09 4:14 ` Jason Wang
2024-09-09 15:20 ` Willem de Bruijn
2024-09-09 21:09 ` Willem de Bruijn
2024-09-10 1:12 ` Willem de Bruijn [this message]
2024-09-09 9:45 ` Szabolcs Nagy
2024-09-09 11:14 ` Mark Brown
2024-09-09 15:14 ` Sudeep Holla
2024-09-09 15:21 ` Willem de Bruijn
2024-09-09 10:13 ` Yury Khrustalev
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=66df9d10e88d2_81fd329432@willemb.c.googlers.com.notmuch \
--to=willemdebruijn.kernel@gmail.com \
--cc=alexander.duyck@gmail.com \
--cc=arefev@swemel.ru \
--cc=broonie@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jakub@cloudflare.com \
--cc=jasowang@redhat.com \
--cc=kuba@kernel.org \
--cc=mst@redhat.com \
--cc=nbd@nbd.name \
--cc=nd@arm.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=szabolcs.nagy@arm.com \
--cc=willemb@google.com \
--cc=yury.khrustalev@arm.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