netdev - net: xilinx: axienet: Query about checksum partial implementation

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240726120700.GA1694627@kernel.org>
Date: Fri, 26 Jul 2024 13:07:00 +0100
From: Simon Horman <horms@...nel.org>
To: Radhey Shyam Pandey <radhey.shyam.pandey@....com>
Cc: Daniel Borkmann <daniel@...earbox.net>,
	Ariane Keller <ariane.keller@....ee.ethz.ch>,
	Michal Simek <michal.simek@....com>, netdev@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: net: xilinx: axienet: Query about checksum partial implementation

Hi Radhey, all,

I am wondering if you could shed some light on the following
checksum partial handling in the axienet_rx_poll():

                        /* if we're doing Rx csum offload, set it up */
                        if (lp->features & XAE_FEATURE_FULL_RX_CSUM) {
				...
                        } else if ((lp->features & XAE_FEATURE_PARTIAL_RX_CSUM) != 0 &&
                                   skb->protocol == htons(ETH_P_IP) &&
                                   skb->len > 64) {
                                skb->csum = be32_to_cpu(cur_p->app3 & 0xFFFF);
                                ...
                        }

In particluar the "skb->csum =" line.

The type of cur_p->app3 is u32, and 0xFFFF is also host byte order.
So far so good. But after the bitwise operation it is treated
as a big-endian value by passing it to be32_to_cpu.

Perhaps I am missing something obvious, but my question is how does that work?

* Was it only tested on big endian sysgtems where be32_to_cpu() is a no-op

* Was it only tested on little endian systems where be32_to_cpu()
  is a byteswap and somehow that works (how?).

* Is the code unecessised because the XAE_FEATURE_FULL_RX_CSUM branch is
  always taken?

  A grep of dts files shows up arch/microblaze/boot/dts/system.dts which
  sets sets xlnx,rxcsum to 0, which corresponds to XAE_NO_CSUM_OFFLOAD.

* Something else

Flagged by Sparse

The in quesoitn code seems to have been introduced by
8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")