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: <667e7f0d78f39_2185b294c5@willemb.c.googlers.com.notmuch>
Date: Fri, 28 Jun 2024 05:14:53 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jakub Sitnicki <jakub@...udflare.com>, 
 netdev@...r.kernel.org
Cc: "David S. Miller" <davem@...emloft.net>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Paolo Abeni <pabeni@...hat.com>, 
 Willem de Bruijn <willemb@...gle.com>, 
 kernel-team@...udflare.com
Subject: Re: [PATCH net-next v2 1/2] udp: Allow GSO transmit from devices with
 no checksum offload

Jakub Sitnicki wrote:
> Today sending a UDP GSO packet from a TUN device results in an EIO error:
> 
>   import fcntl, os, struct
>   from socket import *
> 
>   TUNSETIFF = 0x400454CA
>   IFF_TUN = 0x0001
>   IFF_NO_PI = 0x1000
>   UDP_SEGMENT = 103
> 
>   tun_fd = os.open("/dev/net/tun", os.O_RDWR)
>   ifr = struct.pack("16sH", b"tun0", IFF_TUN | IFF_NO_PI)
>   fcntl.ioctl(tun_fd, TUNSETIFF, ifr)
> 
>   os.system("ip addr add 192.0.2.1/24 dev tun0")
>   os.system("ip link set dev tun0 up")
> 
>   s = socket(AF_INET, SOCK_DGRAM)
>   s.setsockopt(SOL_UDP, UDP_SEGMENT, 1200)
>   s.sendto(b"x" * 3000, ("192.0.2.2", 9)) # EIO
> 
> This is due to a check in the udp stack if the egress device offers
> checksum offload. While TUN/TAP devices, by default, don't advertise this
> capability because it requires support from the TUN/TAP reader.
> 
> However, the GSO stack has a software fallback for checksum calculation,
> which we can use. This way we don't force UDP_SEGMENT users to handle the
> EIO error and implement a segmentation fallback.
> 
> Lift the restriction so that UDP_SEGMENT can be used with any egress
> device. We also need to adjust the UDP GSO code to match the GSO stack
> expectation about ip_summed field, as set in commit 8d63bee643f1 ("net:
> avoid skb_warn_bad_offload false positives on UFO"). Otherwise we will hit
> the bad offload check.
> 
> Users should, however, expect a potential performance impact when
> batch-sending packets with UDP_SEGMENT without checksum offload on the
> egress device. In such case the packet payload is read twice: first during
> the sendmsg syscall when copying data from user memory, and then in the GSO
> stack for checksum computation. This double memory read can be less
> efficient than a regular sendmsg where the checksum is calculated during
> the initial data copy from user memory.
> 
> Signed-off-by: Jakub Sitnicki <jakub@...udflare.com>

Reviewed-by: Willem de Bruijn <willemb@...gle.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ