netdev - Re: [PATCH net-next-2.6] net: Fix some corner cases in dev_can

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]

Message-ID: <AANLkTin+H0MKSesUKXSLzi55TrdoJMxmBhAcr=p-N6S0@mail.gmail.com>
Date:	Tue, 26 Oct 2010 11:11:32 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next-2.6] net: Fix some corner cases in dev_can_checksum()

On Tue, Oct 26, 2010 at 6:29 AM, Ben Hutchings
<bhutchings@...arflare.com> wrote:
> Jesse Gross wrote:
>> On Fri, Oct 22, 2010 at 7:12 AM, Ben Hutchings
>> <bhutchings@...arflare.com> wrote:
>> > dev_can_checksum() incorrectly returns true in these cases:
>> >
>> > 1. The skb has both out-of-band and in-band VLAN tags and the device
>> >   supports checksum offload for the encapsulated protocol but only with
>> >   one layer of encapsulation.
>> > 2. The skb has a VLAN tag and the device supports generic checksumming
>> >   but not in conjunction with VLAN encapsulation.
>> >
>> > Rearrange the VLAN tag checks to avoid these.
>> >
>> > Signed-off-by: Ben Hutchings <bhutchings@...arflare.com>
>>
>> If we assume that cards cannot handle offloading for double tagged
>> packets, which is obviously the most conservative approach, we
>> probably also need to change the checks for TSO/SG.  There's no issue
>> with extracting the protocol from the right header but we might assume
>> that the card can handle double tag offloading when it can't.  For
>> both TSO/SG we check if there is either an in-band tag or out-of-band
>> tag and use dev->vlan_features if that is the case.  Maybe we need to
>> handle it in software if it is double tagged.
>
> That's something to check.
>
>> On the other hand, I don't know whether it's true that cards can't
>> handle offloading for packets tagged in both manners.  I suppose that
>> it depends on where the offloading and tagging are in the pipeline.
>> For example, when it comes to SG I doubt that the cards care about
>> vlan tags much at all.
>
> I do know that current Solarflare controllers can parse two VLAN tags
> and generate/validate TCP/IP-style checksums after them.  We could add
> vlan2_features which would be copied to a VLAN sub-device's
> vlan_features, but then what happens when people want to handle triple
> VLAN encapsulation?

I agree, it's definitely a losing battle to keep adding vlan_features
to handle n + 1 tags.  I was just thinking that we might be able to
make some assumptions about packets tagged out-of-band, since the NIC
doesn't need to parse them at all.  If the tagging takes place late
enough in the pipeline, it might be completely transparent.

It may not be a valid assumption to make for all NICs though, so it's
probably better to be conservative.  As long as we handle it correctly
in software, we can potentially relax it later in the future.
--
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