From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 4854B5A0274 for ; Wed, 28 Feb 2024 14:26:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709126784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uOCc1hhneFR/OuC0hGtWerXjbxAblrBEcsP0R01lTEA=; b=PfVhclaBet0hAa802w+eftO6rTaQCxo3XUVGDyULWpQ1U5yACOZf0gCS7cttr0NjnUD4j+ a44RqgssPaRquAp0pdNlgcCEOFQIGLXaJhUpRFsJNy0ts9z/k6VNoaMMozJO1v9gAV55t4 3s3fjfW47UnHkZV9yhEQuUbxYbKxswA= Received: from mail-oi1-f199.google.com (mail-oi1-f199.google.com [209.85.167.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-220-yj1MYoKjPZq__WfCZRN8ZA-1; Wed, 28 Feb 2024 08:26:22 -0500 X-MC-Unique: yj1MYoKjPZq__WfCZRN8ZA-1 Received: by mail-oi1-f199.google.com with SMTP id 5614622812f47-3c1b1b13080so1830686b6e.0 for ; Wed, 28 Feb 2024 05:26:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709126781; x=1709731581; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uOCc1hhneFR/OuC0hGtWerXjbxAblrBEcsP0R01lTEA=; b=NMtXizwNhBevixi+ItmBAiNPdUPr5AepQfrfEI0DJfHrxa4ZnCU1G920sFQ64DYbNh cSTImpdHxF1XDv68swfzEDEaw37srdDMCRx1S7fYnzrN8+t2uPmnP+xEV73G4CZLtk28 xkTi4C4qqLuWPAcMilQ4IsYX6SvX5yYeNKOEXkY6NHP5H4ttin9vtQpIZ7ruxOVfp9pL nD8bq3F+4bi2tCSWRf7+LXygaINC3nlEfjTXpDeaFDeJd33idNVW3F0G/zSuNyGM5tS+ 0sIPf+Meyrj+/RCH7CR+xsmJSDR2DVpi+8l5Ohpo5TOiw9qnzjxxf8j3nBLB0CcvOZs+ DqwA== X-Gm-Message-State: AOJu0YyiSpZI8rrG7i5d3fvDeXbAmqT+mw9uLL6E5zncvM3jKA84Vong o+lrvp2JoOaLpPPPlqz1BvnJ/6NqSVLQNflRVXUU6jkaWI9TNLFZDO/ezU1cNVi+d5wSKWwtMZp eitPD0CVGECcCuJFgXO/VWa6xPdO3GSn53cpLfKxjO8yIu3ApiZBFQNXhrg== X-Received: by 2002:a05:6218:2612:b0:17b:7738:de5a with SMTP id oy18-20020a056218261200b0017b7738de5amr15558204rwc.2.1709126781646; Wed, 28 Feb 2024 05:26:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IG/IozXNIvST7AjbQjP8uqhGy/KfQA0TuCq84JWHuNq5widBNAp3FNzQq+h/YgTsWxbQrsepQ== X-Received: by 2002:a05:6218:2612:b0:17b:7738:de5a with SMTP id oy18-20020a056218261200b0017b7738de5amr15558176rwc.2.1709126781091; Wed, 28 Feb 2024 05:26:21 -0800 (PST) Received: from [192.168.100.30] ([82.142.8.70]) by smtp.gmail.com with ESMTPSA id kr2-20020a0562142b8200b0068fcaa599f6sm5174888qvb.67.2024.02.28.05.26.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Feb 2024 05:26:20 -0800 (PST) Message-ID: <04c99072-02ea-46a9-aac6-23116cb05fa1@redhat.com> Date: Wed, 28 Feb 2024 14:26:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 7/9] checksum: introduce functions to compute the header part checksum for TCP/UDP To: David Gibson References: <20240217150725.661467-1-lvivier@redhat.com> <20240217150725.661467-8-lvivier@redhat.com> From: Laurent Vivier In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: 4PDWG2IUZRA2RMV72XJ5KGP7YNXQA56X X-Message-ID-Hash: 4PDWG2IUZRA2RMV72XJ5KGP7YNXQA56X X-MailFrom: lvivier@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 2/19/24 04:08, David Gibson wrote: > On Sat, Feb 17, 2024 at 04:07:23PM +0100, Laurent Vivier wrote: >> The TCP and UDP checksums are computed using the data in the TCP/UDP >> payload but also some informations in the IP header (protocol, >> length, source and destination addresses). >> >> We add two functions, proto_ipv4_header_psum() and >> proto_ipv6_header_psum(), to compute the checksum of the IP >> header part. >> >> Signed-off-by: Laurent Vivier >> --- >> >> Notes: >> v3: >> - function parameters provide tot_len, saddr, daddr and protocol >> rather than an iphdr/ipv6hdr >> >> v2: >> - move new function to checksum.c >> - use _psum rather than _checksum in the name >> - replace csum_udp4() and csum_udp6() by the new function >> >> checksum.c | 67 ++++++++++++++++++++++++++++++++++++++++++------------ >> checksum.h | 4 ++++ >> tcp.c | 44 ++++++++++++++++------------------- >> udp.c | 10 ++++---- >> 4 files changed, 81 insertions(+), 44 deletions(-) >> >> diff --git a/checksum.c b/checksum.c >> index 511b296a9a80..55bf1340a257 100644 >> --- a/checksum.c >> +++ b/checksum.c >> @@ -134,6 +134,30 @@ uint16_t csum_ip4_header(uint16_t tot_len, uint8_t protocol, >> return ~csum_fold(sum); >> } >> >> +/** >> + * proto_ipv4_header_psum() - Calculates the partial checksum of an >> + * IPv4 header for UDP or TCP >> + * @tot_len: Payload length >> + * @proto: Protocol number >> + * @saddr: Source address >> + * @daddr: Destination address >> + * @proto: proto Protocol number >> + * Returns: Partial checksum of the IPv4 header >> + */ >> +uint32_t proto_ipv4_header_psum(uint16_t tot_len, uint8_t protocol, >> + uint32_t saddr, uint32_t daddr) >> +{ >> + uint32_t psum = htons(protocol); >> + >> + psum += (saddr >> 16) & 0xffff; >> + psum += saddr & 0xffff; >> + psum += (daddr >> 16) & 0xffff; >> + psum += daddr & 0xffff; >> + psum += htons(ntohs(tot_len) - 20); >> + >> + return psum; >> +} >> + >> /** >> * csum_udp4() - Calculate and set checksum for a UDP over IPv4 packet >> * @udp4hr: UDP header, initialised apart from checksum >> @@ -150,14 +174,10 @@ void csum_udp4(struct udphdr *udp4hr, >> udp4hr->check = 0; >> >> if (UDP4_REAL_CHECKSUMS) { >> - /* UNTESTED: if we did want real UDPv4 checksums, this >> - * is roughly what we'd need */ >> - uint32_t psum = csum_fold(saddr.s_addr) >> - + csum_fold(daddr.s_addr) >> - + htons(len + sizeof(*udp4hr)) >> - + htons(IPPROTO_UDP); >> - /* Add in partial checksum for the UDP header alone */ >> - psum += sum_16b(udp4hr, sizeof(*udp4hr)); >> + uint32_t psum = proto_ipv4_header_psum(len, IPPROTO_UDP, >> + saddr.s_addr, >> + daddr.s_addr); >> + psum = csum_unfolded(udp4hr, sizeof(struct udphdr), psum); >> udp4hr->check = csum(payload, len, psum); >> } >> } >> @@ -180,6 +200,26 @@ void csum_icmp4(struct icmphdr *icmp4hr, const void *payload, size_t len) >> icmp4hr->checksum = csum(payload, len, psum); >> } >> >> +/** >> + * proto_ipv6_header_psum() - Calculates the partial checksum of an >> + * IPv6 header for UDP or TCP >> + * @payload_len: Payload length >> + * @proto: Protocol number >> + * @saddr: Source address >> + * @daddr: Destination address >> + * Returns: Partial checksum of the IPv6 header >> + */ >> +uint32_t proto_ipv6_header_psum(uint16_t payload_len, uint8_t protocol, >> + struct in6_addr saddr, struct in6_addr daddr) > > Hrm, this is passing 2 16-byte IPv6 addresses by value, which might > not be what we want. The idea here is to avoid the pointer alignment problem (&ip6h->saddr and &ip6h->daddr can be misaligned). Is it a better solution to copy the content of ip6h->saddr and ip6h->daddr to some local variables and then provide the pointers of the local variables to proto_ipv6_header_psum()? > >> +{ >> + uint32_t sum = htons(protocol) + payload_len; > > Uh.. doesn't that need to be htons(payload_len + sizeof(struct > ipv6hdr)) rather than simply payload_len? > payload_len is: - b->ip6h.payload_len (from udp_update_hdr6()) - ip6h->payload_len (from tcp_update_check_tcp6()) and in ip6h payload_len is: - htons(udp6_l2_mh_sock[n].msg_len + sizeof(b->uh)) (from udp_update_hdr6()) - htons(plen + sizeof(struct tcphdr)) (from tcp_fill_ipv6_header()) So this is correct... but csum_udp6() uses "len" from tap_udp6_send(), so there is a bug here. but there is also a problem with proto_ipv4_header_psum() that need host endianness and tcp_update_check_tcp4() provides network endianness... The first idea was to use the value from ip6h payload_len as it is already computed. But mixing network endianness and host endianness appears to be a bad idea... Thanks, Laurent