netdev - Re: [PATCH net-next v3 10/24] ovpn: implement basic RX path (UDP)

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: <ZpkUfMtdrsXc-p6k@hog>
Date: Thu, 18 Jul 2024 15:11:24 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Antonio Quartulli <antonio@...nvpn.net>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
	Sergey Ryazanov <ryazanov.s.a@...il.com>,
	Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
	Andrew Lunn <andrew@...n.ch>, Esben Haabendal <esben@...nix.com>
Subject: Re: [PATCH net-next v3 10/24] ovpn: implement basic RX path (UDP)

2024-07-18, 15:06:19 +0200, Antonio Quartulli wrote:
> On 18/07/2024 12:46, Sabrina Dubroca wrote:
> > Sorry Antonio, I'm only coming back to this now.
> 
> No worries and thanks for fishing this email.
> 
> > 
> > 2024-05-10, 16:41:43 +0200, Antonio Quartulli wrote:
> > > On 10/05/2024 15:45, Sabrina Dubroca wrote:
> > > > 2024-05-06, 03:16:23 +0200, Antonio Quartulli wrote:
> > > > > diff --git a/drivers/net/ovpn/io.c b/drivers/net/ovpn/io.c
> > > > > index 36cfb95edbf4..9935a863bffe 100644
> > > > > --- a/drivers/net/ovpn/io.c
> > > > > +++ b/drivers/net/ovpn/io.c
> > > > > +/* Called after decrypt to write the IP packet to the device.
> > > > > + * This method is expected to manage/free the skb.
> > > > > + */
> > > > > +static void ovpn_netdev_write(struct ovpn_peer *peer, struct sk_buff *skb)
> > > > > +{
> > > > > +	/* packet integrity was verified on the VPN layer - no need to perform
> > > > > +	 * any additional check along the stack
> > > > 
> > > > But it could have been corrupted before it got into the VPN?
> > > 
> > > It could, but I believe a VPN should only take care of integrity along its
> > > tunnel (and this is guaranteed by the OpenVPN protocol).
> > > If something corrupted enters the tunnel, we will just deliver it as is to
> > > the other end. Upper layers (where the corruption actually happened) have to
> > > deal with that.
> > 
> > I agree with that, but I don't think that's what CHECKSUM_UNNECESSARY
> > (especially with csum_level = MAX) would do. CHECKSUM_UNNECESSARY
> > tells the networking stack that the checksum has been verified (up to
> > csum_level+1, so 0 means the first level of TCP/UDP type headers has
> > been validated):
> > 
> > // include/linux/skbuff.h
> > 
> >   * - %CHECKSUM_UNNECESSARY
> >   *
> >   *   The hardware you're dealing with doesn't calculate the full checksum
> >   *   (as in %CHECKSUM_COMPLETE), but it does parse headers and verify checksums
> >   *   for specific protocols. For such packets it will set %CHECKSUM_UNNECESSARY
> >   *   if their checksums are okay.
> > 
> >   *   &sk_buff.csum_level indicates the number of consecutive checksums found in
> >   *   the packet minus one that have been verified as %CHECKSUM_UNNECESSARY.
> >   *   For instance if a device receives an IPv6->UDP->GRE->IPv4->TCP packet
> >   *   and a device is able to verify the checksums for UDP (possibly zero),
> >   *   GRE (checksum flag is set) and TCP, &sk_buff.csum_level would be set to
> >   *   two. If the device were only able to verify the UDP checksum and not
> >   *   GRE, either because it doesn't support GRE checksum or because GRE
> >   *   checksum is bad, skb->csum_level would be set to zero (TCP checksum is
> >   *   not considered in this case).
> > 
> > I think you want CHECKSUM_NONE:
> > 
> >   *   Device did not checksum this packet e.g. due to lack of capabilities.
> > 
> > Then the stack will check if the packet was corrupted.
> 
> I went back to the wireguard code, which I used for inspiration for this
> specific part (we are dealing with the same problem here):
> 
> https://elixir.bootlin.com/linux/v6.10/source/drivers/net/wireguard/receive.c#L376
> 
> basically the idea is: with our encapsulation we can guarantee that what
> entered the tunnel is also exiting the tunnel, without corruption.
> Therefore we claim that checksums are all correct.

Can you be sure that they were correct when they went into the tunnel?
If not, I think you have to set CHECKSUM_NONE.

-- 
Sabrina