netdev - [RFC] skge csum problems

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-next>] [day] [month] [year] [list]

Date:	Mon, 24 Dec 2007 09:43:52 +0000
From:	Al Viro <viro@....linux.org.uk>
To:	netdev@...r.kernel.org
Subject: [RFC] skge csum problems

	Both variants of skge (drivers/net and drivers/net/sk98lin/ resp.)
have the same problem with rx checksums.  They pick checksum from rx
descriptor and use it as-is.  Normally that would be the right thing to
do.  However, skge is told to byteswap descriptors on big-endian boxen.

Checksum is fixed-endian and we want it that way; IOW, what we end up
storing in skb->csum should be fixed-endian as well.  Unless the card
is smart enough to byteswap everything in rx descriptor _except_ the
checksum, we have a trouble - we get a value converted to host-endian
by the general byteswap in descriptor and we must convert it to fixed-endian
ourselves.

FWIW, FreeBSD sk_if sidesteps that mess by not telling the card to 
byteswap, so that's not too informative.  Datasheet on
http://people.freebsd.org/~wpaul/SysKonnect/xmacii_datasheet_rev_c_9-29.pdf
is not clear on what's going on with checksum in byteswapping mode either...

Could somebody with that sucker on a card (all instances I have here are
on-board ones in little-endian boxen) test what's really going on for
big-endian hosts with either driver?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html