| 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
| ||
|
Date: Wed, 9 Dec 2015 12:14:16 +0000 From: Edward Cree <ecree@...arflare.com> To: David Miller <davem@...emloft.net> CC: <netdev@...r.kernel.org>, <tom@...bertland.com> Subject: Re: Checksum offload queries On 08/12/15 17:06, David Miller wrote: > All of the headers get touched anyways as each layer of the stack > demuxes the packet. Therefore there is _ZERO_ cost to use 1's > complement to validate checksums in input. It's always superior. Ah, I understand now, it's touching the memory that's expensive, not adding up the numbers. Thanks for being patient with me :) So that just leaves the question of offloading multiple _TX_ checksums. Remote checksum offload would deal with this but the receiver might not support it, meaning that after decapsulation the packet will have a zero checksum (and still has chances to get corrupted); thus it's not necessarily safe to do unless you control both endpoints and know you have RCO everywhere. Convincing hardware designers to go the HW_CSUM way and only fill in the inner checksum, when their current approach can fill in both inner and outer checksums (though admittedly only for the protocols the hardware knows about), might be difficult. Remember that NICs are going to have packet parsing for those protocols anyway, because they need it for things like Windows-spec RSS, so in the hardware designer's mind, ossified offloads are "free". -- 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
Powered by blists - more mailing lists