netdev - Re: Checksum offload queries

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]

Date:	Wed, 9 Dec 2015 08:08:23 -0800
From:	Tom Herbert <tom@...bertland.com>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Edward Cree <ecree@...arflare.com>,
	David Miller <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Checksum offload queries

On Tue, Dec 8, 2015 at 5:56 PM, Thomas Graf <tgraf@...g.ch> wrote:
> On 12/08/15 at 09:04am, Tom Herbert wrote:
>> There are other reasons why CHECKSUM_COMPLETE is preferable:
>>
>> - CHECKSUM_COMPLETE  is more robust. We have no way to validate that
>> the device is actually correct in CHECKSUM_UNNECESSARY. For instance,
>> how do we know that there isn't some failure in the device where
>> everything is being marked as good even if it's not. With
>> CHECKSUM_COMPLETE it is the host that actually makes the decision of
>> whether the checksum is correct it is highly unlikely that failing
>> checksum calculation on the device won't be detected. HW failures and
>> bugs are real concern.
>> -  CHECKSUM_UNNECESSARY does not report bad checksums. There is a
>> csum_bad flag in the sk_buff that could be set if the driver detects a
>> bad checksum in the packet, but no drivers seem to be setting that
>> currently. So for any packets with bad checksums the stack will need
>> to compute the checksum itself, so this potentially becomes the basis
>> of a DDOS attack. CHECKSUM_COMPLETE does not have this problem, we get
>> the checksum of the packet rather the checksum is correct or not.
>
> If I understood Edward correctly, his proposal would be for the
> card to provide both, the csum as for CHECKSUM_COMPLETE plus the
> validation yes/no hint. It would be up to the kernel to decide
> whether to validate itself or trust the card.
>
> I'm all in favour CHECKSUM_COMPLETE as the only way to go but
> we should be aware that it depends on the penetration of RCO in
> hardware VTEPs.

Thomas, I don't understand what you are saying here. CHECKSUM_COMPLETE
is an interface for drivers providing the computed checksum of a
packet on receive, how is this dependent on any use case or any other
mechanisms?
--
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